ذاكرة المطور الخارجية: كيف بنيت ‘دماغي الثاني’ باستخدام Obsidian و Git لتنظيم المعرفة البرمجية

يا جماعة الخير، السلام عليكم.

قبل كم من سنة، كنت غرقان لشوشتي في مشروع ذكاء اصطناعي معقد. كان فيه خوارزمية لمعالجة الصور، وأذكر إني قضيت يومين كاملين وأنا أحاول أحل مشكلة صغيرة في مكتبة OpenCV… المشكلة كانت في طريقة قراءة قيم البكسلات وتحويلها لمصفوفة معينة. بعد بهدلة وتجريب وتطبيش، زبطت معي. سجلت الحل في بالي، وشعرت بانتصار المبرمج اللي ما حدا بحس فيه غيرنا، وكملت شغل.

بعدها بست شهور، في مشروع ثاني مختلف تماماً، طلعتلي نفس المشكلة! والله يا جماعة كأني بشوفها لأول مرة. قعدت أحك راسي وأحكي “يقطع شرك يا ذاكرة، هاي الشغلة مرت عليّ!”. ضيعت نص يوم وأنا أبحث من جديد في Stack Overflow ومنتديات قديمة، لحد ما بالصدفة لقيت الحل… نفس الحل اللي أنا توصلتله قبل شهور. وقتها حسيت بقهر شديد، مش على الوقت اللي ضاع، بس على المعرفة اللي تبخرت. هنا قررت، لازم ألاقي طريقة، لازم أبني “ذاكرة خارجية” ما بتنسى. ومن هنا بلشت رحلتي مع “الدماغ الثاني”.

لماذا يحتاج المبرمج إلى “دماغ ثانٍ”؟

عالمنا كـ “ديفلوبرز” عالم سريع ومتلاطم الأمواج. كل يوم في تقنية جديدة، فريموورك جديد، تحديث لمكتبة، أو حتى طريقة جديدة لكتابة “Hello World!”. ذاكرتنا البيولوجية، مع كل قدرتها، لها حدود. نحن نعاني من:

  • فيضان المعلومات: كمية هائلة من المقالات، الدروس، والمقتطفات البرمجية التي نقابلها يومياً.
  • تبديل السياق (Context Switching): التنقل بين مشروع وآخر، بين مهمة “فرونت إند” و “باك إند”، يشتت تركيزنا ويجعلنا ننسى التفاصيل الدقيقة.
  • _

  • “ديجافو” الأخطاء: حل نفس المشكلة مراراً وتكراراً لأننا نسينا كيف حللناها في المرة الأولى.

فكرة “الدماغ الثاني” أو الـ Second Brain مش إنك تعترف بضعف ذاكرتك، بل هي ترقية لها. هي نظام خارجي موثوق لتخزين، تنظيم، وربط كل المعرفة اللي بتكتسبها، عشان تقدر ترجعلها وقت الحاجة بسهولة وتفرّغ دماغك الأصلي للإبداع وحل المشاكل الجديدة، مش تذكر القديمة.

الأدوات السحرية: Obsidian و Git

بعد تجارب كثيرة مع أدوات مختلفة (Evernote, Notion, OneNote)، استقريت على ثنائي بعتبره “دريم تيم” لأي مطور: Obsidian و Git. كل واحد فيهم له مهمة محددة، ومع بعض بيكملوا النقص.

Obsidian: المفكرة الرقمية المتشابكة

ببساطة، Obsidian هو تطبيق لتدوين الملاحظات. لكن قوته مش بالبساطة هاي. مميزاته اللي خلتني أتمسك فيه:

  • ملفاتك إلك (Local First): كل ملاحظاتك هي مجرد ملفات نصية بصيغة Markdown على جهازك. ما في شركة بتتحكم فيهم، ما في اشتراك شهري إجباري، ما في خوف إنه الخدمة تتسكر. ملفاتك إلك، ومش لحدا غيرك.
  • الربط ثنائي الاتجاه (Bi-directional Linking): هاي هي الجوهرة. بتقدر تربط الملاحظات ببعضها بسهولة باستخدام [[اسم الملاحظة]]. والأجمل، إنه Obsidian بيورجيك مش بس الروابط اللي طالعة من ملاحظتك، بل كمان كل الملاحظات اللي بترتبط فيها. هذا بيخلق شبكة معرفة مترابطة، زي طريقة عمل دماغنا تماماً.
  • مخصص للمطورين: دعم كامل للـ Markdown، بما في ذلك كتل الأكواد مع تمييز الصيغة (Syntax Highlighting)، وهذا شيء أساسي بالنسبة إلنا.
  • مجتمع وإضافات قوية: فيه كمية إضافات (Plugins) هائلة بتخليك تفصّله على مقاسك بالضبط.

Git: شبكة الأمان وآلة الزمن

كلنا بنعرف Git كأداة لإدارة نسخ الكود، بس ليش ما نستخدمه لإدارة نسخ معرفتنا؟

  • سجل التغييرات (Versioning): كل تغيير بتعمله على ملاحظاتك بتقدر تسجله. بتقدر ترجع بالزمن وتشوف ملاحظتك كيف كانت قبل شهر أو سنة.
  • النسخ الاحتياطي والمزامنة (Backup & Sync): عن طريق ربط مستودع ملاحظاتك بمستودع خاص (Private Repository) على GitHub أو GitLab، بتضمن إنه ملاحظاتك محفوظة في السحابة ومتاحة على كل أجهزتك (العمل، البيت، اللابتوب).
  • راحة البال: ما في خوف من ضياع البيانات. حتى لو انحرق جهازك (لا سمح الله)، معرفتك كلها محفوظة بأمان.

كيف تبني “قبو المعرفة” الخاص بك: دليل عملي خطوة بخطوة

يلا نشتغل عملي. الموضوع أبسط مما بتتخيل.

الخطوة الأولى: تجهيز العدّة

  1. حمّل Obsidian: اذهب إلى موقع Obsidian الرسمي وحمّل النسخة المناسبة لنظام تشغيلك.
  2. أنشئ “قبو” جديد (New Vault): القبو هو مجرد مجلد على جهازك راح يحتوي كل ملاحظاتك. اختر له اسم زي “دماغي-الثاني” أو “MyKnowledgeBase” وحطه في مكان سهل الوصول إليه (مثلاً داخل مجلد Documents).
  3. هيّئ Git: افتح الطرفية (Terminal/CMD) وانتقل لمسار القبو اللي أنشأته.
    cd /path/to/your/vault

    ثم نفذ أمر تهيئة Git:

    git init
  4. أنشئ مستودع خاص على GitHub: اذهب إلى حسابك على GitHub وأنشئ مستودعاً جديداً (New repository). مهم جداً: اجعله خاصاً (Private) حتى لا يرى أحد ملاحظاتك. لا تقم بتهيئة المستودع بملف README أو .gitignore من GitHub.
  5. اربط المحلي بالريموت: سيعطيك GitHub بعض الأوامر لربط مجلدك المحلي بالمستودع البعيد. ستكون شبيهة بالتالي:
    git remote add origin https://github.com/your-username/your-repo-name.git
    git branch -M main
    git push -u origin main

وهيك بنكون جهزنا الأساس. قبوك الآن موجود على جهازك، ومربوط بنسخة احتياطية على GitHub.

الخطوة الثانية: هيكلة المعرفة

في البداية، لا ترهق نفسك بالهيكلة المثالية. ابدأ ببساطة. أنا شخصياً أستخدم هيكلية معدّلة من طريقة PARA الشهيرة، لكن بلمستي الفلسطينية:

  • 01-مشاريع-جارية/: لكل مشروع أعمل عليه حالياً، له مجلد خاص. ملاحظات اجتماعات، مهام، أفكار… كل شيء يتعلق بالمشروع هنا.
  • 02-مجالات-خبرة/: مجلدات للتقنيات والمجالات اللي أهتم بها. مثلاً: /Python, /Docker, /LLMs. هنا أضع الملاحظات العامة والمفاهيم الأساسية.
  • 03-مقتطفات-وحيل/: هذا هو كنز المبرمج. مجلد يحتوي على ملاحظات صغيرة ومركزة. مثلاً “كيفية عمل SSH بدون باسورد” أو “أمر Docker لتنظيف النظام”. كل ملاحظة هي حل لمشكلة صغيرة.
  • 04-أرشيف/: عندما أنتهي من مشروع، أنقل مجلده من “مشاريع-جارية” إلى هنا. المعرفة لا تُحذف، بل تؤرشف.
  • Inbox.md: ملف واحد لكل شيء جديد. فكرة عابرة، رابط أريد قراءته… أرميه هنا، وفي آخر الأسبوع أنظف هذا الملف وأوزع محتوياته على المجلدات المناسبة.

نصيحة من أبو عمر: لا تقدس المجلدات. قوة Obsidian الحقيقية في الروابط [[]]. حتى لو كانت ملاحظاتك في فوضى من المجلدات، طالما هي مترابطة بشكل جيد، ستجد ما تبحث عنه.

الخطوة الثالثة: تدوين الملاحظات كالمحترفين

هنا يبدأ المرح. عند تعلم شيء جديد أو حل مشكلة، افتح Obsidian مباشرة.

مثال عملي: حليت مشكلة في Docker تتعلق بحجم الصور الكبير.

  1. أنشئ ملاحظة جديدة باسم [[تقليل حجم صور Docker]].
  2. اكتب شرحاً بسيطاً للمشكلة.
  3. ضع الحل على شكل خطوات واضحة، مع كتل الأكواد.

# تقليل حجم صور Docker

## المشكلة
عند بناء صور Docker لتطبيقات Python، يكون الحجم كبيراً جداً بسبب وجود أدوات البناء والاعتماديات غير الضرورية في الصورة النهائية.

## الحل: استخدام البناء متعدد المراحل (Multi-stage Builds)
الفكرة هي استخدام مرحلتين في ملف الـ `Dockerfile`. مرحلة للبناء (Builder) تحتوي كل شيء، ومرحلة نهائية (Final) ننسخ إليها فقط الملفات الضرورية من مرحلة البناء.

### مثال `Dockerfile`
```dockerfile
# المرحلة الأولى: البناء
FROM python:3.9-slim as builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

# المرحلة الثانية: التشغيل
FROM python:3.9-slim
WORKDIR /app
COPY --from=builder /app /app
# نضيف رابطاً لملاحظة أخرى ذات صلة!
# هذا مهم جداً لـ [[تأمين حاويات Docker]]
CMD ["python", "main.py"]
```
هذه الطريقة تقلل الحجم بشكل كبير لأن الصورة النهائية لا تحتوي على ملفات `requirements.txt` أو أي أدوات بناء.

لاحظ كيف أضفت رابطاً [[تأمين حاويات Docker]] داخل التعليقات. الآن، عندما أفتح ملاحظة “تقليل حجم صور Docker”، سأرى أنها مرتبطة بـ “تأمين حاويات Docker”، والعكس صحيح. هذه هي شبكة المعرفة التي تنمو مع الوقت.

أتمتة المزامنة: دع السحر يعمل وحده

أن تظل تتذكر تنفيذ أوامر git add, commit, push كل يوم هو أمر ممل. الحل الأمثل هو استخدام إضافة مجتمعية رائعة اسمها Obsidian Git.

  1. اذهب إلى Settings > Community Plugins في Obsidian.
  2. ابحث عن “Obsidian Git” وقم بتثبيته وتفعيله.
  3. من خيارات الإضافة، يمكنك ضبطها لتقوم بعملية الـ Commit والـ Push تلقائياً كل فترة زمنية (مثلاً كل 15 دقيقة) أو عند إغلاق التطبيق.

هذا كل شيء. الآن، نظامك يعمل بشكل آلي بالكامل. كل ما عليك هو الكتابة والربط، والنظام يتكفل بالباقي.

نصائح من “الختيار”: خبرتي الشخصية

  • لا تخف من الفوضى في البداية. دماغك الثاني مثل الحديقة، في البداية تبدو فارغة أو عشوائية، لكن مع الرعاية المستمرة ستزهر.
  • الربط أهم من التصنيف. قضاء ساعة في ربط الملاحظات ببعضها أفضل من قضاء ساعة في تنظيمها في مجلدات مثالية.
  • اجعلها عادة يومية. خصص 5-10 دقائق في نهاية كل يوم عمل لكتابة “ملاحظة يومية” (Daily Note). ماذا تعلمت اليوم؟ ما المشكلة التي واجهتني؟ ما الفكرة التي خطرت لي؟
  • استخدم الوسوم (Tags) للحالات. أنا أستخدم وسوم مثل #فكرة، #للقراءة، #مهم لتصنيف طبيعة الملاحظة وليس موضوعها.
  • قبوك هو أنت. مع الوقت، سيصبح قبو المعرفة هذا انعكاساً لطريقة تفكيرك ورحلتك المهنية. إنه استثمار طويل الأمد في أغلى أصولك: معرفتك.

الخلاصة: ذاكرتك الجديدة، قوتك الخارقة

بناء “دماغ ثانٍ” باستخدام Obsidian و Git ليس مجرد ترف أو موضة. إنه تحول جذري في طريقة تعاملك مع المعرفة كـ “ديفلوبر”. إنه يعني أن كل سطر كود كتبته، كل مشكلة حللتها، وكل درس تعلمته، لن يضيع أبداً. ستصبح أكثر كفاءة، أسرع في حل المشاكل، وأكثر ثقة في قدراتك لأنك تقف على أكتاف “أنت” الماضي.

ابنِ ذاكرتك لبنة لبنة، ومع كل لبنة بتزيد خبرتك وقوتك. ويلا، شد حيلك يا مبرمج! 💪

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوسع والأداء العالي والأحمال

طلبات لا تنتهي؟ كيف أنقذتنا قوائم انتظار الرسائل (Message Queues) من انهيار النظام

أشارككم قصة حقيقية من أرض المعركة البرمجية، كيف انتقلنا من نظام على حافة الانهيار بسبب الضغط، إلى نظام مرن وقابل للتوسع بفضل "قوائم انتظار الرسائل"....

16 مايو، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

كانت بيانات بطاقات عملائنا قنبلة موقوتة: كيف أنقذنا ‘الترميز’ (Tokenization) من جحيم تخزين البيانات الحساسة؟

أشارككم قصة حقيقية من قلب المعركة التقنية، عندما كانت بيانات بطاقات عملائنا قنبلة موقوتة تهدد مستقبل شركتنا. اكتشفوا كيف كانت تقنية "الترميز" (Tokenization) طوق النجاة...

16 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

من الخوادم “الثلجية” إلى الكود: كيف أنقذتنا Terraform من جحيم الانحراف التكويني

أشارككم قصة حقيقية عن معاناة فريقنا مع الخوادم الفريدة التي لا تتكرر، وكيف كانت "البنية التحتية كود" (IaC) باستخدام Terraform هي طوق النجاة الذي أخرجنا...

16 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

المسار المهني المزدوج: كيف أنقذنا أفضل مبرمجينا من “الترقية إلى عدم الكفاءة”؟

كان أفضل مبرمجينا يرحلون أو يتحولون إلى مديرين سيئين. في هذه المقالة، أسرد لكم قصة كيف أنقذنا "المسار المهني المزدوج" من هذا الجحيم، وكيف يمكن...

16 مايو، 2026 قراءة المزيد
اختبارات الاداء والجودة

كانت اختباراتنا 100% ناجحة لكن الكود مليء بالثغرات: كيف أنقذنا “الاختبار الطفري” (Mutation Testing) من جحيم التغطية الزائفة؟

أشارككم قصة حقيقية من ميدان البرمجة، حيث كانت نسبة تغطية الاختبارات (Code Coverage) تخدعنا وتوهمنا بالجودة، إلى أن اكتشفنا "الاختبار الطفري" (Mutation Testing). هذه التقنية...

16 مايو، 2026 قراءة المزيد
أتمتة العمليات

من النشر اليدوي إلى التسليم المستمر: دليلك العملي لبناء أول خط أنابيب CI/CD باستخدام GitHub Actions

مقالة عملية من أبو عمر، مطور فلسطيني، تشرح بالتفصيل كيفية الانتقال من النشر اليدوي المجهد إلى الأتمتة الكاملة باستخدام خطوط أنابيب CI/CD على GitHub Actions....

16 مايو، 2026 قراءة المزيد
نصائح برمجية

كانت بياناتنا مجرد أرقام ونصوص: كيف أنقذتنا الكائنات القيمية (Value Objects) من جحيم الأخطاء الصامتة؟

أشارككم قصة من قلب المعركة البرمجية، كيف كاد خطأ بسيط بسبب البيانات العشوائية أن يكلفنا الكثير. سنتعلم معًا كيف تنقذنا "الكائنات القيمية" (Value Objects) من...

16 مايو، 2026 قراءة المزيد
البودكاست