✅ پست جالبی از کانال @productdraft
پشم های گاومیش رو نزن
موقعیتی رو در نظر بگیرین که
میخواین ماشین تون رو بشورین
اما شلنگ خرابه
میخواین شلنگ بخرین اما فروشگاه بیرون شهره و عوارضی میخواد
همسایه تون کارت عوارضی داره
میرین کارت رو بگیرین میگه چون قبلاً یه بالشت بهتون قرض داده تا اون بالشت رو نیارین کارت رو نمیده
میرین بالشت رو بیارین میبینین یه خرده خالی شده و لازمه یه خورده پشم و اینا جور کنین که درست بشه
و در نهایت میبینین روزی رو که برای ماشین شستن شروع کردین تموم شده و شما دارین پشم گاومیش رو میزنین
در حالی که سطل برا شستن ماشین داشتین
این اصطلاح مربوط به چیزهایی میشه که ما برای انجام دادن شروع شون میکنیم اما میبینیم یه ناقصی داره و هعی یه مرحله میریم عقب که ناقصی رو درست کنیم
جای اینکه یه گام مشکل رو جلو ببریم و حلش کنیم
یه گام مشکل ما رو عقب میبره و ما رو از حل کردنش وا می‌داره
مسأله اینجاست که خیلی در توسعه محصول رایجه
میری یه مساله کاربر رو حل کنی میبینی که اااا فلان بخش مرتبط با دیتا، دیتا خوب جمع نمیکنه، میری دیتا رو درست کنی میبینی مشکل معماری و کد داری، میری معماری رو درست کنی میبینی سخت افزار کم داری نهایت خودتو وسط دیتاسنتر میبینی
در حالی که مشکل کاربر نه صددرصد ولی تا هفتاد درصد با همون دیتا قابل حل بود
دلیل رایجش اون جوری که خودم تجربه کردم
گم شدن هدفه
اونم هدفی که تو هر مرحله نچرخونی‌ش
هدف درجه یک هر مساله‌ای که شروع میشه (بیزینسی یا کاربری) نباید تو مسیر گم بشه چون مشکل واقعی هم با هدفش گم میشه
پشم های گاومیش رو نزن
موقعیتی رو در نظر بگیرین که
میخواین ماشین تون رو بشورین
اما شلنگ خرابه
میخواین شلنگ بخرین اما فروشگاه بیرون شهره و عوارضی میخواد
همسایه تون کارت عوارضی داره
میرین کارت رو بگیرین میگه چون قبلاً یه بالشت بهتون قرض داده تا اون بالشت رو نیارین کارت رو نمیده
میرین بالشت رو بیارین میبینین یه خرده خالی شده و لازمه یه خورده پشم و اینا جور کنین که درست بشه
و در نهایت میبینین روزی رو که برای ماشین شستن شروع کردین تموم شده و شما دارین پشم گاومیش رو میزنین
در حالی که سطل برا شستن ماشین داشتین
این اصطلاح مربوط به چیزهایی میشه که ما برای انجام دادن شروع شون میکنیم اما میبینیم یه ناقصی داره و هعی یه مرحله میریم عقب که ناقصی رو درست کنیم
جای اینکه یه گام مشکل رو جلو ببریم و حلش کنیم
یه گام مشکل ما رو عقب میبره و ما رو از حل کردنش وا می‌داره
مسأله اینجاست که خیلی در توسعه محصول رایجه
میری یه مساله کاربر رو حل کنی میبینی که اااا فلان بخش مرتبط با دیتا، دیتا خوب جمع نمیکنه، میری دیتا رو درست کنی میبینی مشکل معماری و کد داری، میری معماری رو درست کنی میبینی سخت افزار کم داری نهایت خودتو وسط دیتاسنتر میبینی
در حالی که مشکل کاربر نه صددرصد ولی تا هفتاد درصد با همون دیتا قابل حل بود
دلیل رایجش اون جوری که خودم تجربه کردم
گم شدن هدفه
اونم هدفی که تو هر مرحله نچرخونی‌ش
هدف درجه یک هر مساله‌ای که شروع میشه (بیزینسی یا کاربری) نباید تو مسیر گم بشه چون مشکل واقعی هم با هدفش گم میشه
👍18👏2🤯2🤮1
جنگولرن
مطلبی درباره تفاوت == و is از کانال @osmanpydev
✅ مطلبی در مورد تفاوت == و is از کانال @osmanpydev
ما وقتی ی متغیر می‌سازیم، مثلا ی لیست، به این صورت:
list1 = [1, 2, 3, 4]
این متغیری که لیستمون رو بهش نسبت دادیم به ی خونه از حافظه رم اشاره میکنه، یعنی این لیست رو داخل ی خونه رم میذاره و به آدرس اون خونه اشاره میکنه.
حالا ی لیست دیگه بسازیم:
list2 = list1
در واقع ما گفتیم لیست دوم هم به همون آدرسی که لیست یک اشاره میکرد اشاره کنه.
حالا هر تغییری تو لیست یک یا لیست دو ایجاد کنیم اون یکی هم تغییر میکنه، مثلا:
list2.append(5)
نتیجه میشه:
print(list1) -> [1, 2, 3, 4, 5]
print(list2) -> [1, 2, 3, 4, 5]
ولی اگه بیایم بگیم:
list3 = list1[:]
اینجا میگیم ی لیست بساز و آیتم‌های لیست یک رو بریز داخلش، ولی نگفتیم لیست سه = لیست یک؛ بنابراین لیست سه به ی خونه دیگه از حافظه رم اشاره میکنه ولی مقدارش همون مقدار لیست یک هست.
به این ترتیب اگه بگیم:
list3.append(6)
نتیجه میشه:
print(list1) -> [1, 2, 3, 4, 5]
print(list2) -> [1, 2, 3, 4, 5]
print(list3) -> [1, 2, 3, 4, 5, 6]
چون ما دیتای ی خونه دیگه از حافظه رم رو تغییر دادیم و فقط مقدار متغیری که به اون خونه اشاره میکنه تغییر کرد.
برای متوجه شدن این تفاوت میتونید با دستور زیر نتیجه رو ببینید:
print(id(list1))
print(id(list2))
print(id(list3))
تابع id آدرس خونه‌ای که متغیر بهش اشاره میکنه رو میده، اینجا لیست یک و لیست دو ی چیز رو چاپ میکنن ولی لیست سه ی چیز دیگه رو چاپ میکنه.
حالا علامت == فقط مقدار دو تا متغیر رو با هم مقایسه میکنه ولی علامت is میاد هم مقدارشون و هم اینکه به ی خونه اشاره میکنن یا نه رو بررسی میکنه، پس:
list1 is list2 -> True
list1 == list2 -> True
list1 is list3 -> False
list1 == list3 -> False (البته چون اونجا ۶ رو به لیست سه اضافه کردیم)
قبل append
list1 == list3 -> True
این همون مفهوم (کپی سطحی)shallow copy در پایتونه.
روش اول کپی نکرد، بلکه آدرس خونه رم رو به متغیر دوم نسبت داد ولی دومی کپی سطحی کرد.
حالا فرض کنید لیست اول رو به این صورت تعریف کردیم:
list1 = [1, 2, [3, 4], 5]
یعنی ی لیست دیگه هم بعنوان ی آیتم بهش دادیم، یعنی بعبارتی لیست تو در تو ایجاد کردیم.
اینجا اگه از روش کپی سطحی استفاده کنیم بازم همون مشکل اول بوجود میاد؛ چون باز آدرس خونه رم لیست داخلی رو داد به متغیر دومی.
list2 = list1[:]
حالا فرض کنید تغییر رو بصورت زیر اعمال کردیم:
list2[2][0] = 9
دوباره خروجی لیست اول رو ببینید:
print(list1) -> [1, 2, [9, 4], 5]
چطور میتونیم جلوی این مشکل رو بگیریم و بعبارتی ی (کپی عمیق)deepcopy داشته باشیم؟
با استفاده از کتابخونه داخلی copy:
import copy
list2 = copy.deepcopy(list1)
البته میشه با همین کتابخونه هم ی کپی سطحی داشت، بصورت زیر:
list3 = copy.copy(list1)
سعی میکنم بیشتر درموردش صحبت کنم.
ما وقتی ی متغیر می‌سازیم، مثلا ی لیست، به این صورت:
list1 = [1, 2, 3, 4]
این متغیری که لیستمون رو بهش نسبت دادیم به ی خونه از حافظه رم اشاره میکنه، یعنی این لیست رو داخل ی خونه رم میذاره و به آدرس اون خونه اشاره میکنه.
حالا ی لیست دیگه بسازیم:
list2 = list1
در واقع ما گفتیم لیست دوم هم به همون آدرسی که لیست یک اشاره میکرد اشاره کنه.
حالا هر تغییری تو لیست یک یا لیست دو ایجاد کنیم اون یکی هم تغییر میکنه، مثلا:
list2.append(5)
نتیجه میشه:
print(list1) -> [1, 2, 3, 4, 5]
print(list2) -> [1, 2, 3, 4, 5]
ولی اگه بیایم بگیم:
list3 = list1[:]
اینجا میگیم ی لیست بساز و آیتم‌های لیست یک رو بریز داخلش، ولی نگفتیم لیست سه = لیست یک؛ بنابراین لیست سه به ی خونه دیگه از حافظه رم اشاره میکنه ولی مقدارش همون مقدار لیست یک هست.
به این ترتیب اگه بگیم:
list3.append(6)
نتیجه میشه:
print(list1) -> [1, 2, 3, 4, 5]
print(list2) -> [1, 2, 3, 4, 5]
print(list3) -> [1, 2, 3, 4, 5, 6]
چون ما دیتای ی خونه دیگه از حافظه رم رو تغییر دادیم و فقط مقدار متغیری که به اون خونه اشاره میکنه تغییر کرد.
برای متوجه شدن این تفاوت میتونید با دستور زیر نتیجه رو ببینید:
print(id(list1))
print(id(list2))
print(id(list3))
تابع id آدرس خونه‌ای که متغیر بهش اشاره میکنه رو میده، اینجا لیست یک و لیست دو ی چیز رو چاپ میکنن ولی لیست سه ی چیز دیگه رو چاپ میکنه.
حالا علامت == فقط مقدار دو تا متغیر رو با هم مقایسه میکنه ولی علامت is میاد هم مقدارشون و هم اینکه به ی خونه اشاره میکنن یا نه رو بررسی میکنه، پس:
list1 is list2 -> True
list1 == list2 -> True
list1 is list3 -> False
list1 == list3 -> False (البته چون اونجا ۶ رو به لیست سه اضافه کردیم)
قبل append
list1 == list3 -> True
این همون مفهوم (کپی سطحی)shallow copy در پایتونه.
روش اول کپی نکرد، بلکه آدرس خونه رم رو به متغیر دوم نسبت داد ولی دومی کپی سطحی کرد.
حالا فرض کنید لیست اول رو به این صورت تعریف کردیم:
list1 = [1, 2, [3, 4], 5]
یعنی ی لیست دیگه هم بعنوان ی آیتم بهش دادیم، یعنی بعبارتی لیست تو در تو ایجاد کردیم.
اینجا اگه از روش کپی سطحی استفاده کنیم بازم همون مشکل اول بوجود میاد؛ چون باز آدرس خونه رم لیست داخلی رو داد به متغیر دومی.
list2 = list1[:]
حالا فرض کنید تغییر رو بصورت زیر اعمال کردیم:
list2[2][0] = 9
دوباره خروجی لیست اول رو ببینید:
print(list1) -> [1, 2, [9, 4], 5]
چطور میتونیم جلوی این مشکل رو بگیریم و بعبارتی ی (کپی عمیق)deepcopy داشته باشیم؟
با استفاده از کتابخونه داخلی copy:
import copy
list2 = copy.deepcopy(list1)
البته میشه با همین کتابخونه هم ی کپی سطحی داشت، بصورت زیر:
list3 = copy.copy(list1)
سعی میکنم بیشتر درموردش صحبت کنم.
👍18🤮1
✅ مطلب مفیدی درباره Logging از کانال @PyHints
یک دوستی دیروز راجب لاگ نویسی توی پایتون سوال داشت من به اینصورت براش توضیح دادم گفتم شاید مفید باشه :
نشون میده هر دسته از لاگ رو چطور باید باهاش برخورد کرد بطور کلی ۵ دسته بندی برامون خیلی مهم هستندکه به ترتیب از محیط توسعه و اطلاعات بیشتر به سمت محیط پروداکشن و وضعیت خطرناک تر میریم :
نسخه روزانه فقط اطلاعات سطح
نسخه ماهانه اما جاهایی هست که
اما بطور کلی warning , … خطاهای نرم افزار رو لاگ میکنه مثلا اگر سرور ارور 500 برای کاربری فرستاد تحت چه شرایطی و به چه دلیل این اتفاق افتاده و …
توی اکثر سناریوها لاگ ها بعد از یک مدت بصورت اتوماتیک بررسی میشن و تحت شرایطی خاص به ادمین سرور یا توسعه دهنده یا … هشداری رو ارسال میکنند پس اینکه چه اطلاعاتی به چه صورتی نوشته بشه مهم هست و وظیفه
بعنوان مثال روی پروژه‌های مهم لاگ‌های سطح
بنظرم دونستن اهمیت این ۴ تا کامپوننت؛ برای لاگ نویسی از هرچیزی مهمتر هست.
@PyHints
یک دوستی دیروز راجب لاگ نویسی توی پایتون سوال داشت من به اینصورت براش توضیح دادم گفتم شاید مفید باشه :
Python logging components :وضعیت لاگ؛ همیشه لازم هست.
1- Loggers
نشون میده هر دسته از لاگ رو چطور باید باهاش برخورد کرد بطور کلی ۵ دسته بندی برامون خیلی مهم هستندکه به ترتیب از محیط توسعه و اطلاعات بیشتر به سمت محیط پروداکشن و وضعیت خطرناک تر میریم :
debug - info - warning - error - critical
معمولا روی محیط توسعه از debug استفاده میکنیم و روی محیط پروداکشن شخصا ۲ تا نسخه نگه میدارم یک نسخه که روزانه پاک میشه (به این وضعیت اتومات حذف شدن هم logrotate گفته میشه اصطلاحا) و یک نسخه هم که ماهانه rotate میشه ولی تا ۱ سال گذشته رو نگهداری میکنیم. نسخه روزانه فقط اطلاعات سطح
info رو نگهداری میکنه؛ بیشتر برای این نگهداری میکنیم که بدونیم چه کسی؛ چه زمانی؛ چیکار کرده ؟نسخه ماهانه اما جاهایی هست که
warning - error - critical
داشتیم؛ ی وقتایی ممکنه از لاگ info برای warning استفاده بشه : برای مثال ممکنه یک یوزر با رفتار امن شروع کنه به درخواست زیاد فرستادن به یکی از لاگین ها اینجا جایی هست که میشه لاگ info رو بررسی کرد و اطلاعات اون یوزر رو توی warning هم داشت اما بطور کلی warning , … خطاهای نرم افزار رو لاگ میکنه مثلا اگر سرور ارور 500 برای کاربری فرستاد تحت چه شرایطی و به چه دلیل این اتفاق افتاده و …
2- Formatters
از قدیم گفتن لاگ بدون فرمت بدرد صاحب کد هم نمیخوره؛توی اکثر سناریوها لاگ ها بعد از یک مدت بصورت اتوماتیک بررسی میشن و تحت شرایطی خاص به ادمین سرور یا توسعه دهنده یا … هشداری رو ارسال میکنند پس اینکه چه اطلاعاتی به چه صورتی نوشته بشه مهم هست و وظیفه
formatter هم دقیقا همین هست. مثلا : warning sample.py unauthorized requests to resource at 2023-06-20 17:16:15 from 192.168.1.5 response code 401بطور کلی مشخص میکنه با هر پیام لاگی که میاد چیکار باید کرد ؟ اینکه برای info فایل جدا داشته باشیم یا یک سری از اطلاعات رو داخل کنسول / ترمینال نمایش بدیم و … توسط ایشون انجام میشه
3- Handlers
بعنوان مثال روی پروژه‌های مهم لاگ‌های سطح
critical رو بصورت ایمیل یا پیامک برای چند شخص می‌فرستیم تا سریعتر بررسی بشه و این کار توسط Handler انجام میشه 4- Filtersممکنه توی لاگ نویسی یک سری از اطلاعات محرمانه باشه و تحت هیچ شرایطی نباید توی لاگ بیاد مثلا توی مثال بالا ممکن بود من توی اطلاعات لاگ هم بگم که خب شماره موبایل کاربری که داره اینکار رو میکنه هم داشته باشیم اما قطعا بیزینس نمیخواد این اطلاعات توی لاگ هایی که آرشیو میکنه یا ممکنه به یک شرکت دیگری برای بررسی بده وجود داشته باشه پس در نهایت یک فیلتر می‌نویسه که برخی از این اطلاعات که محرمانه هستند حذف بشه یا با یک مقدار از پیش تعیین شده جایگزین بشه.
بنظرم دونستن اهمیت این ۴ تا کامپوننت؛ برای لاگ نویسی از هرچیزی مهمتر هست.
@PyHints
👍11🤮2
✅ یه مثال جنگویی که باهاش میشه با کاربرد annotate و Case و When و Value آشنا بشیم.
فرض کنید شما یک مدل به نام Product دارید که فیلدهای name و price داره.
الان می‌خوایم براساس قیمت محصول، یه فیلد جدید به اسم price_status تعیین کنیم.
اگه قیمت محصول بیشتر از 100 باشه، می‌خوایم price_status رو "گران" قرار بدیم و در غیر این صورت "ارزان".
اگه این کد ایرادی داره یا روش های دیگه ای بلدید کامنت کنید. با تشکر از دوست خوبمون
فرض کنید شما یک مدل به نام Product دارید که فیلدهای name و price داره.
الان می‌خوایم براساس قیمت محصول، یه فیلد جدید به اسم price_status تعیین کنیم.
اگه قیمت محصول بیشتر از 100 باشه، می‌خوایم price_status رو "گران" قرار بدیم و در غیر این صورت "ارزان".
اگه این کد ایرادی داره یا روش های دیگه ای بلدید کامنت کنید. با تشکر از دوست خوبمون
👍12❤1👎1👏1🤮1
✅ Command not found: django-admin
این خطا رو معمولا دوستانی که تازه شروع میکنن به یادگیری جنگو می بینن
جنگو رو نصب کردن. اما سیستم شون دستور django-admin رو نمی شناسه
توی لینکی که گذاشتم سر سوال و جواب های زیادی هست که بعضی شون درست هستن
✔️ اما در کل بخوام بگم. وقتی django رو نصب می کنید (توی ویندوز. بقیه رو نمیدونم) یه فایل به اسم django-admin.py توی فولدر scripts اضافه میشه. این فولدر هم وقتی پایتون رو نصب می کنیم به path سیستم اضافه شده (توی عکس ها مشخصه) لذا django-admin رو میزنیم کار میکنه. اما اگه scripts رو نداشته باشیم یا توی path نباشه. نمی شناسش
✔️ البته این مشکل مختص ویندوز نیست.
یکی از روش هایی که توی کامنت ها هست اینه:
py -m django startproject myproject
داره با -m ماژول django رو صدا میزنه. و startproject هم یکی از کامندهای django هست. پس کار میکنه.
قاعدتا venv داشته باشید از این داستانها نخواهید داشت.
لینک stackoverflow:
https://stackoverflow.com/questions/8250086/command-not-found-django-admin-py
این خطا رو معمولا دوستانی که تازه شروع میکنن به یادگیری جنگو می بینن
جنگو رو نصب کردن. اما سیستم شون دستور django-admin رو نمی شناسه
توی لینکی که گذاشتم سر سوال و جواب های زیادی هست که بعضی شون درست هستن
✔️ اما در کل بخوام بگم. وقتی django رو نصب می کنید (توی ویندوز. بقیه رو نمیدونم) یه فایل به اسم django-admin.py توی فولدر scripts اضافه میشه. این فولدر هم وقتی پایتون رو نصب می کنیم به path سیستم اضافه شده (توی عکس ها مشخصه) لذا django-admin رو میزنیم کار میکنه. اما اگه scripts رو نداشته باشیم یا توی path نباشه. نمی شناسش
✔️ البته این مشکل مختص ویندوز نیست.
یکی از روش هایی که توی کامنت ها هست اینه:
py -m django startproject myproject
داره با -m ماژول django رو صدا میزنه. و startproject هم یکی از کامندهای django هست. پس کار میکنه.
قاعدتا venv داشته باشید از این داستانها نخواهید داشت.
لینک stackoverflow:
https://stackoverflow.com/questions/8250086/command-not-found-django-admin-py
👍6
✅ پیاده سازی Django Soft Delete
از کانال @microfrontend_ir
چندی پیش خبری منتشر شد که در توییتر حذف داده‌ها به درستی انجام نمی‌شود. واقعیت این است که در اغلب نرم‌افزارهای مدرن داده‌ها به صورت فیزیکی حذف نمی‌شوند و صرفا برچسپ حذف شده می‌گیرند. در این ویدیو با هدف آشنایی بیشتر با مدل‌های abstract و proxy در جنگو و همچنین ایجاد Custom Queryset و Custom Manager و Custom Admin Action مدلی را طراحی کردیم که در صورت ارث بری از آنها داده‌ها با دستور حذف به صورت فیزیکی پاک نشوند و در صورت لزوم برگردانده شوند. برای توضیح بیشتر نیز به جنگو ادمین یک اکشن اضافه کردیم که داده‌هایی که حذف شده اند را برکردانیم
Link: https://youtu.be/I_23u4xj1Ws
PlayList: https://youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv
〰️〰️〰️〰️〰️
© @microfrontend_ir
از کانال @microfrontend_ir
چندی پیش خبری منتشر شد که در توییتر حذف داده‌ها به درستی انجام نمی‌شود. واقعیت این است که در اغلب نرم‌افزارهای مدرن داده‌ها به صورت فیزیکی حذف نمی‌شوند و صرفا برچسپ حذف شده می‌گیرند. در این ویدیو با هدف آشنایی بیشتر با مدل‌های abstract و proxy در جنگو و همچنین ایجاد Custom Queryset و Custom Manager و Custom Admin Action مدلی را طراحی کردیم که در صورت ارث بری از آنها داده‌ها با دستور حذف به صورت فیزیکی پاک نشوند و در صورت لزوم برگردانده شوند. برای توضیح بیشتر نیز به جنگو ادمین یک اکشن اضافه کردیم که داده‌هایی که حذف شده اند را برکردانیم
Link: https://youtu.be/I_23u4xj1Ws
PlayList: https://youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv
〰️〰️〰️〰️〰️
© @microfrontend_ir
👍2
✅ چطور تغییرات Stash شده در Git را به کامپیوتر دیگر منتقل کنیم
فرض کنید تغییراتی روی پروژه داشتید و به هر دلیلی اونارو با دستور git stash به stash اضافه کردید (فارسی انگلیسی کنار هم سخته)
حالا به هر دلیل دیگه ای میخواهید که این تغییرات رو توی فولدر دیگه یا کامپیوتر دیگری منتقل کنید. (دیدم که میگم)
یک راهش اینه که کل فولدر گیت (که مخفی هست) رو کپی کنید. که واقعا راه خوبی نیست.
راه دومش export کردن تغییرات stash شده در git با دستورات خود git هست. مسیر زیر رو ببینید (اول stash کنید):
git stash show "stash@{0}" -p > changes.patch
git apply changes.patch
همونطوری که مشخصه بعد از stash کردن هر stash یک Revision داره که اینجا
stash@{0}
هست. با این میتونید به stash مد نظرتون اشاره کنید.
بعد از اجرای این خط یه فایل به اسم changes.patch کنار فولدر گیت (که مخفی هست) ساخته میشه. میتونید اینو کپی کنید و کنار فولدر git مقصد بزارید و دستور آخر رو اجرا کنید.
برای من که جالب بود. امیدوارم برای شما هم جالب بوده باشه :)
https://gist.github.com/jioo/eebe4c39d800baf99c0db703ded4842c
فرض کنید تغییراتی روی پروژه داشتید و به هر دلیلی اونارو با دستور git stash به stash اضافه کردید (فارسی انگلیسی کنار هم سخته)
حالا به هر دلیل دیگه ای میخواهید که این تغییرات رو توی فولدر دیگه یا کامپیوتر دیگری منتقل کنید. (دیدم که میگم)
یک راهش اینه که کل فولدر گیت (که مخفی هست) رو کپی کنید. که واقعا راه خوبی نیست.
راه دومش export کردن تغییرات stash شده در git با دستورات خود git هست. مسیر زیر رو ببینید (اول stash کنید):
git stash show "stash@{0}" -p > changes.patch
git apply changes.patch
همونطوری که مشخصه بعد از stash کردن هر stash یک Revision داره که اینجا
stash@{0}
هست. با این میتونید به stash مد نظرتون اشاره کنید.
بعد از اجرای این خط یه فایل به اسم changes.patch کنار فولدر گیت (که مخفی هست) ساخته میشه. میتونید اینو کپی کنید و کنار فولدر git مقصد بزارید و دستور آخر رو اجرا کنید.
برای من که جالب بود. امیدوارم برای شما هم جالب بوده باشه :)
https://gist.github.com/jioo/eebe4c39d800baf99c0db703ded4842c
👍5🔥3
✅ از Linkedin آقای arash hosseini #مهندسی_سیستم لینک در نظرات پست
مهندسی سیستم بخش چهارم:
نقطه یا وضعیت تعادل در سیستم :
هر سیستم طبیعی یا دست ساخته ای در تعادل با محیط عملیاتی خود می باشد. به این موضوع "تعادل قدرت" گفته می شود . این تعادل وابسته به وضعیت وجودی سیستم در مرتبه تسلط و تابعیت از دیگر سیستم ها می باشد. در هر نقطه ای از زمان، یک سیستم معمولا بر اساس یک وضعیت ابتدایی با شرایط، ایستایی، داینامیک ، قدرت، ضعف یا پایداری و یک وضعیت نهایی با رفتار، محصول، لوازم یا نتایج برگرفته از مدل سرویس گرایی که با تعادل قدرت کنترل می شود ، تعریف می گردد.
پیش نیاز ها :
پایداری، یکپارچگی و ثبات کارکردی نیازمند تبدیل و انتقالی بدون ابهام و انشعاب در میان فازها، عملیات ها و کارهای سیستم است. بنابراین از نظر طراحان سیستم فرض براین است که شرایط یا معیارهای پیش نیاز یا اولیه باید قبل از ورود به فاز، عملیات یا کار بعدی محقق شوند. بر اساس تعریف، از آنجایی که یک سیستم از اجزایی یکپارچه تشکیل شده است، این مهم است که اجزا همزمانی و هماهنگی داشته باشند.
وضعیت و شرایط اولیه عملیات :
شرایط اولیه عملیات شامل وضعیت های فیزیکی، عملیاتی و محیط اطراف در شروع فاز ماموریت، عملیات یا کار می باشد. از آنجایی که آنالیز، نیازمند استقرار مفروضات اولیه جنبه های گوناگون فازها، عملیات ها یا کارهای سیستم است. شرایط اولیه به عنوان یک تصویر یا نقطه شروعی است که مفروضات را دربر می گیرد. برای تشریح این مفهوم مثال ذیل را در نظر بگیرید :
مثال : هواپیما در شرایط باد مقابل با سرعت 35گره از زمین برخاست، ساعت پرترافیک صبح با کولاکی به سرعت باد 30 مایل در ساعت که از سمت دریا می وزید آغاز گردید.
استاتیک :
زمانی که ما یک سیستم را آنالیز می کنیم، بعضا وضعیت فیزیکی کلید پایه ای برای آنالیز سیستم در یک لحظه از زمان می باشد. ایستایی برای مشخص کردن جهت سیستم در لحظه حال، مانند یک وضعیت برداری یا چرخش در درون یک سیستم بزرگ تر است . از زاویه دید کلان به سیستم، هواپیمایی که در آشیانه قرار دارد، اتومبیلی که درون یک راهرو قرار گرفته یا شبکه ای بدون ترافیک پیام ها و یا سیستمی روشنایی با 2 وضعیت روشن و خاموش همگی ارائه کننده یک سیستم در وضعیت ایستا هستند. در مقابل اجزای لایه های درونی سیستم مانند کامپوننت ها ممکن است در شرایط ایستا باشند در حالیکه مجموعه سیستم در یک دینامیک قرار دارد.
دینامیک ماموریت :
هر سیستمی چه طبیعی و چه دست ساخته انسان، ماموریت خود را در محیط عملیاتش در فرمی از دینامیک، وضعیت فیزیکی انجام می دهد. دینامیک ها مشخصه های ایستای سیستم در فریم مشخصی از گذر زمان در محیط عملیاتی هستند . دینامیک ها می توانند همانند طیف از حرکت آهسته صخره ای در دامنه یک تپه، تغییرات متوسط مانند تغییرات دما و در نهایت تغییرات ناگهانی مانند زمین لرزه باشد.
دینامیک ها در ناسازگاری‌ها، آشفتگی‌ها و بی ثباتی ها در "تعادل قدرت" با محیط داخلی یا بیرونی اتفاق می افتند. نوع بشر همواره علاقمند به بررسی دینامیک ها و تاثیرآنها بر الگوهای رفتاری زمین، آب و هوا، اقیانوس ها، بازار سهام ومردم، بخصوص زمانی که اثر ویرانگر اقتصادی یا امنیتی داشته، بوده است. بنابر این پیش بینی پیشرفت در رویه های معمول کسب وکارها و تکنولوژی، خود کسب وکاری بسیار بزرگ است . چون ما نیاز داریم که با اطمینان رفتار و عملکرد یک سیستم را در شرایط دینامیک عملیاتی پیش بینی کنیم.
ادامه در کامنت
مهندسی سیستم بخش چهارم:
نقطه یا وضعیت تعادل در سیستم :
هر سیستم طبیعی یا دست ساخته ای در تعادل با محیط عملیاتی خود می باشد. به این موضوع "تعادل قدرت" گفته می شود . این تعادل وابسته به وضعیت وجودی سیستم در مرتبه تسلط و تابعیت از دیگر سیستم ها می باشد. در هر نقطه ای از زمان، یک سیستم معمولا بر اساس یک وضعیت ابتدایی با شرایط، ایستایی، داینامیک ، قدرت، ضعف یا پایداری و یک وضعیت نهایی با رفتار، محصول، لوازم یا نتایج برگرفته از مدل سرویس گرایی که با تعادل قدرت کنترل می شود ، تعریف می گردد.
پیش نیاز ها :
پایداری، یکپارچگی و ثبات کارکردی نیازمند تبدیل و انتقالی بدون ابهام و انشعاب در میان فازها، عملیات ها و کارهای سیستم است. بنابراین از نظر طراحان سیستم فرض براین است که شرایط یا معیارهای پیش نیاز یا اولیه باید قبل از ورود به فاز، عملیات یا کار بعدی محقق شوند. بر اساس تعریف، از آنجایی که یک سیستم از اجزایی یکپارچه تشکیل شده است، این مهم است که اجزا همزمانی و هماهنگی داشته باشند.
وضعیت و شرایط اولیه عملیات :
شرایط اولیه عملیات شامل وضعیت های فیزیکی، عملیاتی و محیط اطراف در شروع فاز ماموریت، عملیات یا کار می باشد. از آنجایی که آنالیز، نیازمند استقرار مفروضات اولیه جنبه های گوناگون فازها، عملیات ها یا کارهای سیستم است. شرایط اولیه به عنوان یک تصویر یا نقطه شروعی است که مفروضات را دربر می گیرد. برای تشریح این مفهوم مثال ذیل را در نظر بگیرید :
مثال : هواپیما در شرایط باد مقابل با سرعت 35گره از زمین برخاست، ساعت پرترافیک صبح با کولاکی به سرعت باد 30 مایل در ساعت که از سمت دریا می وزید آغاز گردید.
استاتیک :
زمانی که ما یک سیستم را آنالیز می کنیم، بعضا وضعیت فیزیکی کلید پایه ای برای آنالیز سیستم در یک لحظه از زمان می باشد. ایستایی برای مشخص کردن جهت سیستم در لحظه حال، مانند یک وضعیت برداری یا چرخش در درون یک سیستم بزرگ تر است . از زاویه دید کلان به سیستم، هواپیمایی که در آشیانه قرار دارد، اتومبیلی که درون یک راهرو قرار گرفته یا شبکه ای بدون ترافیک پیام ها و یا سیستمی روشنایی با 2 وضعیت روشن و خاموش همگی ارائه کننده یک سیستم در وضعیت ایستا هستند. در مقابل اجزای لایه های درونی سیستم مانند کامپوننت ها ممکن است در شرایط ایستا باشند در حالیکه مجموعه سیستم در یک دینامیک قرار دارد.
دینامیک ماموریت :
هر سیستمی چه طبیعی و چه دست ساخته انسان، ماموریت خود را در محیط عملیاتش در فرمی از دینامیک، وضعیت فیزیکی انجام می دهد. دینامیک ها مشخصه های ایستای سیستم در فریم مشخصی از گذر زمان در محیط عملیاتی هستند . دینامیک ها می توانند همانند طیف از حرکت آهسته صخره ای در دامنه یک تپه، تغییرات متوسط مانند تغییرات دما و در نهایت تغییرات ناگهانی مانند زمین لرزه باشد.
دینامیک ها در ناسازگاری‌ها، آشفتگی‌ها و بی ثباتی ها در "تعادل قدرت" با محیط داخلی یا بیرونی اتفاق می افتند. نوع بشر همواره علاقمند به بررسی دینامیک ها و تاثیرآنها بر الگوهای رفتاری زمین، آب و هوا، اقیانوس ها، بازار سهام ومردم، بخصوص زمانی که اثر ویرانگر اقتصادی یا امنیتی داشته، بوده است. بنابر این پیش بینی پیشرفت در رویه های معمول کسب وکارها و تکنولوژی، خود کسب وکاری بسیار بزرگ است . چون ما نیاز داریم که با اطمینان رفتار و عملکرد یک سیستم را در شرایط دینامیک عملیاتی پیش بینی کنیم.
ادامه در کامنت
👍3
✅ از Linkedin آقای arash hosseini #مهندسی_سیستم لینک در نظرات پست
مهندسی سیستم بخش پنجم:
فصلی جدید :
نقش های سیستم و ذی نفعان
هر سیستمی در جهان هستی دارای مقصود و ماموریتی می باشد. به بیان دیگر، هر سیستمی یک دلیل وجودی برای هستیش در ارتباط با دیگر سیستم ها دارد . بیشتر سیستم های دست ساخته بشر به سمت مشارکت و دریافت نقش ها، ماموریت ها و اهداف سازمان مالک خود هدایت می شوند. هر سیستم نقش و بازی در مجموعه سیستم های مالک خود می پذیرد. مسیر موفقیت سیستم های دست ساخته در رسیدن به موفقیت در سازمان به اینکه چقدر خوب مشخص، طراحی، توسعه، یکپارچه، تائید، بررسی، عمل و پشتیبانی شده اند. در این مورد نیاز به منافع مقرری است که به صورت مستقیم یا غیر مستقیم از طریق اثربخشی عملیاتی نتایج ماموریت، کارایی دریافت شده و خروجی اهداف سیستم انسان هایی را متاثر نماید. ما به این افراد به عنوان ذی نفعان سیستم اشاره می کنیم. ابتدا به تعاریف پایه بپردازیم :
کاربر نهایی : فرد یا سازمانی که به صورت مستقیم از منافع خروجی یا نتیجه یک سیستم، محصول یا خدمت بهره مند می گردد.
ذی نفع : فرد یا سازمانی که منافع از پیش تعیین شده ای (دوستانه، رقابتی، یا متخاصم) در خروجی تولید شده از یک سیستم در انجام ماموریت تعیین شده اش دارد.
کاربر سیستم : فرد یا سازمانی که یک سیستم، محصول یا خدمت یا لوازمش را در جهت انجام دادن یک کار یا ماموریت هدفمند بکار می گیرد. برای مثال یک سیستم حمل و نقل شهری رانندگان و اتوبوس ها را برای جابجایی افراد از نقطه ای به نقطه دیگر به کار می گیرد. راننده اتوبوس و مسافران در دسته بندی کاربر قرار می گیرند.
نقش های سیستم سازمانی : سیستم های سازمانی نقش هایی را بازی می کنند که نمایان گر جایگاه آنها در چارت ماموریت ها و اهداف دامنه کسب وکاریشان می باشد. به عنوان مثال سیستم های قضایی که وظیفه و نقش داوری افراد، سازمان های کوچک و بزرگ در انطباق با قوانین، اساسنامه ها، آئین نامه ها، احکام و سیاست ها را بازی می کنند یا سیستم حمل و نقل که مشتریان و کالاها را قادر به جابجایی در امنیت از یک نقطه به یک نقطه دیگر در روی زمین، دریا، آسمان و فضا یا ترکیبی از آنها می نماید یا سیسم آموزش که امکانات آموزشی برای افزایش دانش و مهارت افراد را برای ایفای نقش مفیدتر در جامعه، مهیا می سازد
زمینه نقش سیستم :
هر سیستم دست ساخته ای، عملیات ها و کارهایی در جهت ماموریت خود برای دستیابی به اهداف و نتایج خاص مبتنی بر عملکرد برای حمایت از مشتریان، کاربران و ذینفعان خود انجام می دهد. اگر این سیستم ها را بررسی کنید شما به دو نقش همزمان و زمینه ای سیستم می رسید یک نقش ماموریتی سیستم و یک نقش پشتیبانی سیستم .
ادامه در کامنت
مهندسی سیستم بخش پنجم:
فصلی جدید :
نقش های سیستم و ذی نفعان
هر سیستمی در جهان هستی دارای مقصود و ماموریتی می باشد. به بیان دیگر، هر سیستمی یک دلیل وجودی برای هستیش در ارتباط با دیگر سیستم ها دارد . بیشتر سیستم های دست ساخته بشر به سمت مشارکت و دریافت نقش ها، ماموریت ها و اهداف سازمان مالک خود هدایت می شوند. هر سیستم نقش و بازی در مجموعه سیستم های مالک خود می پذیرد. مسیر موفقیت سیستم های دست ساخته در رسیدن به موفقیت در سازمان به اینکه چقدر خوب مشخص، طراحی، توسعه، یکپارچه، تائید، بررسی، عمل و پشتیبانی شده اند. در این مورد نیاز به منافع مقرری است که به صورت مستقیم یا غیر مستقیم از طریق اثربخشی عملیاتی نتایج ماموریت، کارایی دریافت شده و خروجی اهداف سیستم انسان هایی را متاثر نماید. ما به این افراد به عنوان ذی نفعان سیستم اشاره می کنیم. ابتدا به تعاریف پایه بپردازیم :
کاربر نهایی : فرد یا سازمانی که به صورت مستقیم از منافع خروجی یا نتیجه یک سیستم، محصول یا خدمت بهره مند می گردد.
ذی نفع : فرد یا سازمانی که منافع از پیش تعیین شده ای (دوستانه، رقابتی، یا متخاصم) در خروجی تولید شده از یک سیستم در انجام ماموریت تعیین شده اش دارد.
کاربر سیستم : فرد یا سازمانی که یک سیستم، محصول یا خدمت یا لوازمش را در جهت انجام دادن یک کار یا ماموریت هدفمند بکار می گیرد. برای مثال یک سیستم حمل و نقل شهری رانندگان و اتوبوس ها را برای جابجایی افراد از نقطه ای به نقطه دیگر به کار می گیرد. راننده اتوبوس و مسافران در دسته بندی کاربر قرار می گیرند.
نقش های سیستم سازمانی : سیستم های سازمانی نقش هایی را بازی می کنند که نمایان گر جایگاه آنها در چارت ماموریت ها و اهداف دامنه کسب وکاریشان می باشد. به عنوان مثال سیستم های قضایی که وظیفه و نقش داوری افراد، سازمان های کوچک و بزرگ در انطباق با قوانین، اساسنامه ها، آئین نامه ها، احکام و سیاست ها را بازی می کنند یا سیستم حمل و نقل که مشتریان و کالاها را قادر به جابجایی در امنیت از یک نقطه به یک نقطه دیگر در روی زمین، دریا، آسمان و فضا یا ترکیبی از آنها می نماید یا سیسم آموزش که امکانات آموزشی برای افزایش دانش و مهارت افراد را برای ایفای نقش مفیدتر در جامعه، مهیا می سازد
زمینه نقش سیستم :
هر سیستم دست ساخته ای، عملیات ها و کارهایی در جهت ماموریت خود برای دستیابی به اهداف و نتایج خاص مبتنی بر عملکرد برای حمایت از مشتریان، کاربران و ذینفعان خود انجام می دهد. اگر این سیستم ها را بررسی کنید شما به دو نقش همزمان و زمینه ای سیستم می رسید یک نقش ماموریتی سیستم و یک نقش پشتیبانی سیستم .
ادامه در کامنت
👍1
✅ مطلبی از کانال @TorhamDevCH در مورد DRF
https://testdriven.io/blog/drf-serializers/
این مقاله از اوناست که همیشه دوباره بهش سر میزنی :).
اگه مقدماتی DRF رو بلدید برای عمیق تر شدن این مقاله گزینه خیلی خوبیه. باهاش چندتا از متدها مفید سریالایزرها رو یادمیگرید و میفهمید چطوری میشه overrideشون کرد. 🤝
آپدیت منبع اصلی:
بچه ها حقیقت عمیق شدن داخل DRF اینه که شما متدها مختلف سریالایزر میخونید و override میکنید و کلا میفهمید اون متد داره چیکار میکنه. دیگه ته اعماق DRF اینه که شما میتونید کلا serializer چطور کار میکنه.
مثلا شما یک متد دارید داخل سریالایزر save این متد خودش متد update صدا میزنه و در آپدیت در نهایت شما میایید متد save خود مدل جنگو رو صدا میزنید و اینطور میشه که اگر شما یک instance و دیتا به سریالایزر پاس بدید وقتی save میکنید در اصل اپدیت هم خواهید کرد.
https://testdriven.io/blog/drf-serializers/
این مقاله از اوناست که همیشه دوباره بهش سر میزنی :).
اگه مقدماتی DRF رو بلدید برای عمیق تر شدن این مقاله گزینه خیلی خوبیه. باهاش چندتا از متدها مفید سریالایزرها رو یادمیگرید و میفهمید چطوری میشه overrideشون کرد. 🤝
آپدیت منبع اصلی:
بچه ها حقیقت عمیق شدن داخل DRF اینه که شما متدها مختلف سریالایزر میخونید و override میکنید و کلا میفهمید اون متد داره چیکار میکنه. دیگه ته اعماق DRF اینه که شما میتونید کلا serializer چطور کار میکنه.
مثلا شما یک متد دارید داخل سریالایزر save این متد خودش متد update صدا میزنه و در آپدیت در نهایت شما میایید متد save خود مدل جنگو رو صدا میزنید و اینطور میشه که اگر شما یک instance و دیتا به سریالایزر پاس بدید وقتی save میکنید در اصل اپدیت هم خواهید کرد.
testdriven.io
Effectively Using Django REST Framework Serializers
This article looks at how to use Django REST Framework (DRF) serializers more efficiently and effectively.
🔥4❤1
Forwarded from نوشته‌های ترمینالی
اگر شما می‌خواستین stackoverflow رو طراحی کنید چه کار میکردید؟ احتمالا جواب خیلیا با اون حجم کاربر microservice باشه.
ولی جواب اینه که خیر. یه monolith روی چند تا سروره و تمام!
توی یه قسمت از خبرنامه‌ی bytebytego میتونید در موردش بخونید:
https://blog.bytebytego.com/p/ep27-stack-overflow-architecture
در مورد اینکه چطوری به این performance می‌رسن، این صفحه از stack exchange هم جالبه:
https://stackexchange.com/performance
ولی جواب اینه که خیر. یه monolith روی چند تا سروره و تمام!
توی یه قسمت از خبرنامه‌ی bytebytego میتونید در موردش بخونید:
https://blog.bytebytego.com/p/ep27-stack-overflow-architecture
در مورد اینکه چطوری به این performance می‌رسن، این صفحه از stack exchange هم جالبه:
https://stackexchange.com/performance
Bytebytego
EP27: Stack Overflow Architecture. Also...
This week’s system design refresher:
👍2
✅ خلاصه کتاب - 97 نکته که هر معمار/مهندس نرم افزار باید بداند
از لینکدین Hamed Banaei
لینک مطلب:
https://www.linkedin.com/pulse/%25D8%25AE%25D9%2584%25D8%25A7%25D8%25B5%25D9%2587-%25DA%25A9%25D8%25AA%25D8%25A7%25D8%25A8-97-%25D9%2586%25DA%25A9%25D8%25AA%25D9%2587-%25DA%25A9%25D9%2587-%25D9%2587%25D8%25B1-%25D9%2585%25D9%2587%25D9%2586%25D8%25AF%25D8%25B3-%25D9%2586%25D8%25B1%25D9%2585-%25D8%25A7%25D9%2581%25D8%25B2%25D8%25A7%25D8%25B1-%25D8%25A8%25D8%25A7%25DB%258C%25D8%25AF-%25D8%25A8%25D8%25AF%25D8%25A7%25D9%2586%25D8%25AF1-hamed-banaei/?trackingId=zTwpUdT5RRWeppZRBoLYnw%3D%3D
✔️ متن مقاله در نظرات
از لینکدین Hamed Banaei
لینک مطلب:
https://www.linkedin.com/pulse/%25D8%25AE%25D9%2584%25D8%25A7%25D8%25B5%25D9%2587-%25DA%25A9%25D8%25AA%25D8%25A7%25D8%25A8-97-%25D9%2586%25DA%25A9%25D8%25AA%25D9%2587-%25DA%25A9%25D9%2587-%25D9%2587%25D8%25B1-%25D9%2585%25D9%2587%25D9%2586%25D8%25AF%25D8%25B3-%25D9%2586%25D8%25B1%25D9%2585-%25D8%25A7%25D9%2581%25D8%25B2%25D8%25A7%25D8%25B1-%25D8%25A8%25D8%25A7%25DB%258C%25D8%25AF-%25D8%25A8%25D8%25AF%25D8%25A7%25D9%2586%25D8%25AF1-hamed-banaei/?trackingId=zTwpUdT5RRWeppZRBoLYnw%3D%3D
✔️ متن مقاله در نظرات
👍2
✅ مطلبی در مورد index ها در PostgreSQL از کانال @djangoex
در پستگرس (PostgreSQL) چند نوع مختلف شاخص یا ایندکس (Index) وجود دارد که هر کدام برای کاربردهای خاصی طراحی شده اند. در زیر به معرفی و بررسی آنها می‌پردازم:
یک. B-tree: این نوع شاخص، پیش فرض برای هر نوع داده‌ها می‌باشد. سریعترین ایندکس برای عملیات مقایسه‌ای مانند =, <, <=, >, >= می‌باشد.
دو. Hash: این نوع از شاخص فقط برای عملیات مساوی (=) سریع است و برای سایر عملیات‌های مقایسه‌ای کارآیی مناسبی ندارد.
سه. GiST (Generalized Search Tree): این شاخص پشتیبانی می کند از و نسخه سازگاری بسیار پذیر است که از حوزه های داده و عملیات مقایسه متنوعی پشتیبانی می کند.
چهار. SP-GiST (Space-Partitioned Generalized Search Tree): این نوع شاخص فراهم می کند برای انواع مختلفی از بازیابی های داده، به خصوص زمانی که داده ها یک ساختار فضایی شیر نمی کند.
پنج. GIN (Generalized Inverted Index): این شاخص مناسب برای داده‌هایی است که مقادیر چندگانه در یک سطر دارند، مانند آرایه‌ها و JSON.
شش. BRIN (Block Range INdex): این شاخص مناسب برای جداول بزرگ است که سطرهای آنها به طور فیزیکی بر اساس برخی مقادیر مرتب شده‌اند.
برای مطالعه بیشتر حول این موضوع میتوانید به مستندات PostgreSQL مراجعه نمایید.
در پستگرس (PostgreSQL) چند نوع مختلف شاخص یا ایندکس (Index) وجود دارد که هر کدام برای کاربردهای خاصی طراحی شده اند. در زیر به معرفی و بررسی آنها می‌پردازم:
یک. B-tree: این نوع شاخص، پیش فرض برای هر نوع داده‌ها می‌باشد. سریعترین ایندکس برای عملیات مقایسه‌ای مانند =, <, <=, >, >= می‌باشد.
دو. Hash: این نوع از شاخص فقط برای عملیات مساوی (=) سریع است و برای سایر عملیات‌های مقایسه‌ای کارآیی مناسبی ندارد.
سه. GiST (Generalized Search Tree): این شاخص پشتیبانی می کند از و نسخه سازگاری بسیار پذیر است که از حوزه های داده و عملیات مقایسه متنوعی پشتیبانی می کند.
چهار. SP-GiST (Space-Partitioned Generalized Search Tree): این نوع شاخص فراهم می کند برای انواع مختلفی از بازیابی های داده، به خصوص زمانی که داده ها یک ساختار فضایی شیر نمی کند.
پنج. GIN (Generalized Inverted Index): این شاخص مناسب برای داده‌هایی است که مقادیر چندگانه در یک سطر دارند، مانند آرایه‌ها و JSON.
شش. BRIN (Block Range INdex): این شاخص مناسب برای جداول بزرگ است که سطرهای آنها به طور فیزیکی بر اساس برخی مقادیر مرتب شده‌اند.
برای مطالعه بیشتر حول این موضوع میتوانید به مستندات PostgreSQL مراجعه نمایید.
PostgreSQL Documentation
11.2. Index Types
11.2. Index Types # 11.2.1. B-Tree 11.2.2. Hash 11.2.3. GiST 11.2.4. SP-GiST 11.2.5. GIN 11.2.6. BRIN PostgreSQL provides several index types: …
❤2
Forwarded from ProgrammingSchool (Python)
قسمت اول: قراردادهای پایتون
در یک مجموعه از پست‌ها، قراردادهایی که در هنگام کدنویسی پایتون باید رعایت شوند معرفی می‌شوند. این قراردادها از پروژه‌های مشهور و کتابخانه‌های استاندارد پایتون گرفته شده‌اند و در طول زمان تکامل پیدا میکنند.
In a series of posts, the conventions that must be followed when coding in Python are introduced. These conventions are taken from popular Python projects and standard libraries and evolve over time.
این قراردادها خوانایی کد را بالا می‌برند. خوانایی کد، مهمتر از نوشتن کد است. هر برنامه‌نویسی که کار توسعه نرم‌افزار را انجام می‌دهد باید با این قراردادها آشنایی کامل داشته باشد. در پست بعد در مورد Hanging indent ها صحبت میکنیم.
These conventions improve code readability. Code readability is more important than code writing. Every programmer who does software development should be familiar with these contracts. we will talk about hanging indents in the next post.
#آموزش_پایتون
#قراردادهای_پایتون
آدرس کانال:
@Programmingschool2
سایت آموزشی:
https://programmingschool.ir
در یک مجموعه از پست‌ها، قراردادهایی که در هنگام کدنویسی پایتون باید رعایت شوند معرفی می‌شوند. این قراردادها از پروژه‌های مشهور و کتابخانه‌های استاندارد پایتون گرفته شده‌اند و در طول زمان تکامل پیدا میکنند.
In a series of posts, the conventions that must be followed when coding in Python are introduced. These conventions are taken from popular Python projects and standard libraries and evolve over time.
این قراردادها خوانایی کد را بالا می‌برند. خوانایی کد، مهمتر از نوشتن کد است. هر برنامه‌نویسی که کار توسعه نرم‌افزار را انجام می‌دهد باید با این قراردادها آشنایی کامل داشته باشد. در پست بعد در مورد Hanging indent ها صحبت میکنیم.
These conventions improve code readability. Code readability is more important than code writing. Every programmer who does software development should be familiar with these contracts. we will talk about hanging indents in the next post.
#آموزش_پایتون
#قراردادهای_پایتون
آدرس کانال:
@Programmingschool2
سایت آموزشی:
https://programmingschool.ir
👍3
Forwarded from ProgrammingSchool (Python)
قسمت دوم: قراردادهای پایتون
تورفتگی‌های Hanging Indent
خطوطی که بیش از ۷۹ کاراکتر دارند باید به صورت عمودی نوشته شوند. در هنگام نوشتن عمودی، باید پیوستگی خط حفظ شود. یکی از راه‌های حفظ پیوستگی، استفاده از پرانتز یا براکت است. تراز شدن خطوط با استفاده از Hanging indent انجام می‌شود. تورفتگی Hanging یک سبک نوشتاری است که در آن تمام خطوط یک پاراگراف به جز خط اول تورفتگی دارند. در پایتون، این اصطلاح برای توصیف سبکی استفاده می‌شود که در آن پرانتز آغازین یک عبارت پرانتزدار، آخرین کاراکتر خط اول است و خطوط بعدی تا پرانتز بسته، تورفتگی دارند.
Lines longer than 79 characters must be written vertically. Line continuity must be maintained when writing vertically. One of the ways to maintain continuity is to use parentheses or brucet. Alignment of lines is done using Hanging indent. Hanging indentation is a writing style in which all lines of a paragraph are indented except for the first line. In Python, this term is used to describe a style in which the opening parenthesis of a parenthesized expression is the last character of the first line, and subsequent lines are indented up to the closing parenthesis.
هنگام استفاده از تورفتگی‌های Hanging باید در نظر گرفت که خط اول نباید هیچ آرگومانی داشته باشد. همچنین می‌توان از تورفتگی‌های بیشتر برای تشخیص واضح خطوط مذکور استفاده شود.
When using hanging indents, note that the first line should not have any arguments. Also, more indentations can be used to clearly distinguish the mentioned lines.
#آموزش_پایتون
#قراردادهای_پایتون
آدرس کانال:
@Programmingschool2
سایت آموزشی:
https://programmingschool.ir
گروه پرسش و پاسخ:
https://t.iss.one/programmingschool_group
تورفتگی‌های Hanging Indent
خطوطی که بیش از ۷۹ کاراکتر دارند باید به صورت عمودی نوشته شوند. در هنگام نوشتن عمودی، باید پیوستگی خط حفظ شود. یکی از راه‌های حفظ پیوستگی، استفاده از پرانتز یا براکت است. تراز شدن خطوط با استفاده از Hanging indent انجام می‌شود. تورفتگی Hanging یک سبک نوشتاری است که در آن تمام خطوط یک پاراگراف به جز خط اول تورفتگی دارند. در پایتون، این اصطلاح برای توصیف سبکی استفاده می‌شود که در آن پرانتز آغازین یک عبارت پرانتزدار، آخرین کاراکتر خط اول است و خطوط بعدی تا پرانتز بسته، تورفتگی دارند.
Lines longer than 79 characters must be written vertically. Line continuity must be maintained when writing vertically. One of the ways to maintain continuity is to use parentheses or brucet. Alignment of lines is done using Hanging indent. Hanging indentation is a writing style in which all lines of a paragraph are indented except for the first line. In Python, this term is used to describe a style in which the opening parenthesis of a parenthesized expression is the last character of the first line, and subsequent lines are indented up to the closing parenthesis.
هنگام استفاده از تورفتگی‌های Hanging باید در نظر گرفت که خط اول نباید هیچ آرگومانی داشته باشد. همچنین می‌توان از تورفتگی‌های بیشتر برای تشخیص واضح خطوط مذکور استفاده شود.
When using hanging indents, note that the first line should not have any arguments. Also, more indentations can be used to clearly distinguish the mentioned lines.
#آموزش_پایتون
#قراردادهای_پایتون
آدرس کانال:
@Programmingschool2
سایت آموزشی:
https://programmingschool.ir
گروه پرسش و پاسخ:
https://t.iss.one/programmingschool_group
👍2
✅ از Linkedin آقای arash hosseini #مهندسی_سیستم لینک در نظرات پست
مهندسی سیستم بخش ششم:
پذیرش سیستم :
میزان موفقیت هر سیستم دست ساخته بشر و ماموریتش در شاخص های پذیرش ذیل نهفته است :
· آیا بازار برای پذیرش سیستم جدید آمادگی دارد ؟ یک نیاز عملیاتی به پنجره ای از موقعیت های جدید
· درک کاربر از ابزارهای عملیاتی، سازگاری و در دسترس بودن
· توانایی سیستم در انجام و به ثمر رساندن اهداف کاربر – اثر بخشی سیستم
· بازگشت سرمایه برای منابع وابسته به عملیات و نگهداری سیستم – به صرفه بودن
بیشتر افراد پذیرش سیستم را از دریچه رضایت زمینه کاری مشتری می بینند. مهندسین غالبا اندازه گیری این موضوع را به بعد از ارائه و توزیع سیستم در بازار محول می کنند. بر اساس چیزی که سازمان از نظرسنجی های پس از تحویل می آموزد، مهندسین ممکن است سیستم یا محصول را اصلاح کنند اگر :
· کاربر موقعیتی جدید برای رفع کمبودها، طی یک قرارداد توسعه به آنها ارائه نماید. البته کمبودهایی که در قرارداد اولیه در نظر گرفته نشده باشد.
· پیش بینی های سود بلندمدت سرمایه گذاری داخلی را ارزشمندتر نماید.
شما به عنوان یک مهندس سیستم باید نیازهای عملیاتی کاربر را قبل از توسعه و نظر سنجی درک نمائید، شما باید درک کنید که :
· کاربر قرار است چگونه از سیستم یا محصول شما استفاده نماید ؟
· چه معیارهایی برای موفقیت باید اعمال شود ؟
· پیامد شکست کاربر و بوجود آمدن شاخه های جدید از درجاتی از موفقیت چیست ؟
اگر توسعه دهندگان سیستم شاخص موفقیت برای پذیرش سیستم از طرف کاربر را درک ننمایند، بهترین طراحی نیز بیهوده خواهد بود، در نتیجه این موضوع یکی از مفاهیم پایه در مهندسی سیستم خواهد بود. شاخص های پذیرش یاد شده اگر چه از نظر روانی برابر به نظر می رسند، بندرت به صورت همزمان در حالت مطلوب قرار می گیرند. معیارهای ذهنی - یعنی درک از ابزارهای عملیاتی، مناسب بودن و دسترس پذیری، اغلب معیارهای عینی موفقیت سیستم (اثربخشی . به صرفه بودن) را مبهم می نماید.
· فاکتورهای نگاه ذهنی ، حس و درک در جامعه همتایان سیستم یا منبع سرمایه گذاری قالبا پذیرش موفقیت سیستم از دید کاربر را تا اندازه ای تیره تار می نماید.
· در مقابل، کاربر برای همان دلایل ذهنی ممکن است موفقیت عینی یک سیستم را زیر سوال ببرد.
در نهایت، برخی از رویدادها بررسی واقعیت را ممکن می سازد. یک تصمیم برای ادامه کار با یک سیستم ممکن است منجر به ایجاد نیاز به یک بروزرسانی برای تصحیح کمبودها، حذف تدریجی یک سیستم یا جایگزینی آن با یک سیستم جدید گردد. یک آن
ابزار عملیاتی، مناسب، در دسترس و موثر پیش ران اطمینان از وجود مهندسی سیستم به عنوان یکی از اجزای اصلی توسعه کلان از ایده تا ارائه نهایی می‌باشد. این فاکتورها به مانند شعار در میان بازاریاب ها مرسوم هستند و اغلب اندازه گیری آنها برای پیاده سازی بسیار دشوار می باشد. به طور معمول پیاده سازی سیستم نیاز به متخصصینی دارد که میزان قابل توجهی از تمرکز عمر کاری خود را بر اندازه گیری و ارائه این اطلاعات به نحوی که واقعی و قابل فهم برای تصمیم گیران کلیدی باشد، صرف کرده اند.
چالش های کلیدی توسعه سیستم های قابل پذیرش از طرف کاربران :
موفقیت و درجه پذیرش سیستم، محصول یا خدمت غالبا به کمک پاسخ به مجموعه ای سوالات که با آنالیز قبل از توسعه و با بازخورد و دریافت نتایج بعد از توسعه اندازه گیری می شود، اندازه گیری می شود. سوالاتی شامل موارد ذیل :
ادامه در کامنت
مهندسی سیستم بخش ششم:
پذیرش سیستم :
میزان موفقیت هر سیستم دست ساخته بشر و ماموریتش در شاخص های پذیرش ذیل نهفته است :
· آیا بازار برای پذیرش سیستم جدید آمادگی دارد ؟ یک نیاز عملیاتی به پنجره ای از موقعیت های جدید
· درک کاربر از ابزارهای عملیاتی، سازگاری و در دسترس بودن
· توانایی سیستم در انجام و به ثمر رساندن اهداف کاربر – اثر بخشی سیستم
· بازگشت سرمایه برای منابع وابسته به عملیات و نگهداری سیستم – به صرفه بودن
بیشتر افراد پذیرش سیستم را از دریچه رضایت زمینه کاری مشتری می بینند. مهندسین غالبا اندازه گیری این موضوع را به بعد از ارائه و توزیع سیستم در بازار محول می کنند. بر اساس چیزی که سازمان از نظرسنجی های پس از تحویل می آموزد، مهندسین ممکن است سیستم یا محصول را اصلاح کنند اگر :
· کاربر موقعیتی جدید برای رفع کمبودها، طی یک قرارداد توسعه به آنها ارائه نماید. البته کمبودهایی که در قرارداد اولیه در نظر گرفته نشده باشد.
· پیش بینی های سود بلندمدت سرمایه گذاری داخلی را ارزشمندتر نماید.
شما به عنوان یک مهندس سیستم باید نیازهای عملیاتی کاربر را قبل از توسعه و نظر سنجی درک نمائید، شما باید درک کنید که :
· کاربر قرار است چگونه از سیستم یا محصول شما استفاده نماید ؟
· چه معیارهایی برای موفقیت باید اعمال شود ؟
· پیامد شکست کاربر و بوجود آمدن شاخه های جدید از درجاتی از موفقیت چیست ؟
اگر توسعه دهندگان سیستم شاخص موفقیت برای پذیرش سیستم از طرف کاربر را درک ننمایند، بهترین طراحی نیز بیهوده خواهد بود، در نتیجه این موضوع یکی از مفاهیم پایه در مهندسی سیستم خواهد بود. شاخص های پذیرش یاد شده اگر چه از نظر روانی برابر به نظر می رسند، بندرت به صورت همزمان در حالت مطلوب قرار می گیرند. معیارهای ذهنی - یعنی درک از ابزارهای عملیاتی، مناسب بودن و دسترس پذیری، اغلب معیارهای عینی موفقیت سیستم (اثربخشی . به صرفه بودن) را مبهم می نماید.
· فاکتورهای نگاه ذهنی ، حس و درک در جامعه همتایان سیستم یا منبع سرمایه گذاری قالبا پذیرش موفقیت سیستم از دید کاربر را تا اندازه ای تیره تار می نماید.
· در مقابل، کاربر برای همان دلایل ذهنی ممکن است موفقیت عینی یک سیستم را زیر سوال ببرد.
در نهایت، برخی از رویدادها بررسی واقعیت را ممکن می سازد. یک تصمیم برای ادامه کار با یک سیستم ممکن است منجر به ایجاد نیاز به یک بروزرسانی برای تصحیح کمبودها، حذف تدریجی یک سیستم یا جایگزینی آن با یک سیستم جدید گردد. یک آن
ابزار عملیاتی، مناسب، در دسترس و موثر پیش ران اطمینان از وجود مهندسی سیستم به عنوان یکی از اجزای اصلی توسعه کلان از ایده تا ارائه نهایی می‌باشد. این فاکتورها به مانند شعار در میان بازاریاب ها مرسوم هستند و اغلب اندازه گیری آنها برای پیاده سازی بسیار دشوار می باشد. به طور معمول پیاده سازی سیستم نیاز به متخصصینی دارد که میزان قابل توجهی از تمرکز عمر کاری خود را بر اندازه گیری و ارائه این اطلاعات به نحوی که واقعی و قابل فهم برای تصمیم گیران کلیدی باشد، صرف کرده اند.
چالش های کلیدی توسعه سیستم های قابل پذیرش از طرف کاربران :
موفقیت و درجه پذیرش سیستم، محصول یا خدمت غالبا به کمک پاسخ به مجموعه ای سوالات که با آنالیز قبل از توسعه و با بازخورد و دریافت نتایج بعد از توسعه اندازه گیری می شود، اندازه گیری می شود. سوالاتی شامل موارد ذیل :
ادامه در کامنت
🔥3
✅ بجای کد نویس بودن، برنامه نویس باشید!
بعضی از مطالبی که پست میکنم. شاید اینطور به نظر بیاد که ربطی به کانال جنگولرن ندارن
اما قرار نیست ما کدنویس باشیم. قراره برنامه نویس باشیم و حتی فراتر از برنامه نویس!!!
مطلب زیر رو بخونید. تفاوت کد نویسی و برنامه نویسی رو تقریبا گفته:
https://roocket.ir/articles/programming-or-coding
بعضی از مطالبی که پست میکنم. شاید اینطور به نظر بیاد که ربطی به کانال جنگولرن ندارن
اما قرار نیست ما کدنویس باشیم. قراره برنامه نویس باشیم و حتی فراتر از برنامه نویس!!!
مطلب زیر رو بخونید. تفاوت کد نویسی و برنامه نویسی رو تقریبا گفته:
https://roocket.ir/articles/programming-or-coding
👍10
✅ شروع دوره طراحی الگوریتم از کانال @BenDevelop
توصیه میکنم پیگیر این دوره باشید. نه به خاطر مدرسش (که البته واقعا کارش درسته) به خاطر اینکه یاد گرفتن طراحی الگوریتم میتونه مارو به سمت حرفه ای شدن توی برنامه نویسی سوق بده.
وقتی طراحی الگوریتم و ساختمان داده بلدی. خیلی بهتر میتونی کد بهینه بنویسی که سرعت اجرای بالایی هم داشته باشه و منابع زیادی هم مصرف نکنه.
اینم اولین ویدیو معرفی دوره الگوریتم و ساختمان داده که صحبتش رو کرده بودیم
تو این ویدیو دوره رو معرفی میکنم و توضیح می‌دم که دوره برای چه کسایی هستش و به چه ترتیبی باید ببینیدش
https://youtu.be/kclXvoKsEEY
@BenDevelop
توصیه میکنم پیگیر این دوره باشید. نه به خاطر مدرسش (که البته واقعا کارش درسته) به خاطر اینکه یاد گرفتن طراحی الگوریتم میتونه مارو به سمت حرفه ای شدن توی برنامه نویسی سوق بده.
وقتی طراحی الگوریتم و ساختمان داده بلدی. خیلی بهتر میتونی کد بهینه بنویسی که سرعت اجرای بالایی هم داشته باشه و منابع زیادی هم مصرف نکنه.
اینم اولین ویدیو معرفی دوره الگوریتم و ساختمان داده که صحبتش رو کرده بودیم
تو این ویدیو دوره رو معرفی میکنم و توضیح می‌دم که دوره برای چه کسایی هستش و به چه ترتیبی باید ببینیدش
https://youtu.be/kclXvoKsEEY
@BenDevelop
👍3🔥2
Forwarded from ProgrammingSchool (Python)
قسمت سوم: تورفتگی‌های بخش شرطی if
زمانی که بخش شرطی یک عبارت if طولانی باشد لازم است در چند خط نوشته شود. در این حالت، نوشتن کلمه کلیدی و پرانتز باز در خط اول و بقیه شروط در سایر خطوط ایده جالبی نیست(مشابه Hanging Indent). زیرا باعث تداخل کدهای شرط if با کدهای بلوک آن شود.
When the conditional part of an if-statement is long, it requires to be written on multiple lines. In this case, it isn't an interesting idea to write the keyword if and open parenthesis in the first line and the rest of the conditions in the other lines (similar to Hanging Indent). Because it makes the code less readable.
در این حالت PEP هیچ ایده صریحی ندارد. برخی از شکل های نوشتاری قابل قبول عبارتند از:
In this case, PEP has no clear idea. Some acceptable written forms are:
۱- سایر خطوط مربوط به بخش شرطی، به صورت همتراز با خطوط بلاک if نوشته شود.
1- Other lines related to the conditional section should be alignment to the lines of the if block.
۲- بین خطوط بخش شرطی و دستورهای بلوک if یک خط کامنت قرار می‌دهند.
2- A comment line is placed between the lines of the conditional section and the if block commands
۳- تورفتگی های بخش شرطی، بیشتر از دستورات بلوک if است.
3- The indents of the conditional section are more than the if block commands.
#آموزش_پایتون
#قراردادهای_پایتون
آدرس کانال:
@Programmingschool2
سایت آموزشی:
https://programmingschool.ir
گروه پرسش و پاسخ:
https://t.iss.one/programmingschool_group
زمانی که بخش شرطی یک عبارت if طولانی باشد لازم است در چند خط نوشته شود. در این حالت، نوشتن کلمه کلیدی و پرانتز باز در خط اول و بقیه شروط در سایر خطوط ایده جالبی نیست(مشابه Hanging Indent). زیرا باعث تداخل کدهای شرط if با کدهای بلوک آن شود.
When the conditional part of an if-statement is long, it requires to be written on multiple lines. In this case, it isn't an interesting idea to write the keyword if and open parenthesis in the first line and the rest of the conditions in the other lines (similar to Hanging Indent). Because it makes the code less readable.
در این حالت PEP هیچ ایده صریحی ندارد. برخی از شکل های نوشتاری قابل قبول عبارتند از:
In this case, PEP has no clear idea. Some acceptable written forms are:
۱- سایر خطوط مربوط به بخش شرطی، به صورت همتراز با خطوط بلاک if نوشته شود.
1- Other lines related to the conditional section should be alignment to the lines of the if block.
۲- بین خطوط بخش شرطی و دستورهای بلوک if یک خط کامنت قرار می‌دهند.
2- A comment line is placed between the lines of the conditional section and the if block commands
۳- تورفتگی های بخش شرطی، بیشتر از دستورات بلوک if است.
3- The indents of the conditional section are more than the if block commands.
#آموزش_پایتون
#قراردادهای_پایتون
آدرس کانال:
@Programmingschool2
سایت آموزشی:
https://programmingschool.ir
گروه پرسش و پاسخ:
https://t.iss.one/programmingschool_group
👍1