Forwarded from Pythonism
قابلیت filter شبیه به مپ عمل میکنه با این تفاوت که امکان چک کردن یک شرط رو روی تمام اعضای یک لیست رو فراهم میکنه.
filter(lambda x: x < 0, number_list)
#FXL
#lambda
#filter
#map
#lambda_function
#Anonymous
#true
#expression
filter(lambda x: x < 0, number_list)
#FXL
#lambda
#filter
#map
#lambda_function
#Anonymous
#true
#expression
👍7
Forwarded from یادگیری ماشین با چاشنی صنعت (Abolfazl 🤘)
ساخت ID های منحصر به فرد در دیتابیس های توزیع شده ( قسمت اول)
سلام دوستان عزیز امیدوارم که حالتون خوب باشه. در کنارتون هستیم با یکی از پرکاربرد ترین و مهمترین مسئله های حوزه مهندسی نرم افزار و در حیطه سیستم های توزیع شده.
ما در قسمت قبل کمی درباره سیستم های توزیع شده و همینطور sharding صحبت کردیم و یه دید کلی نسبت بهش به دست آوردیم.
فرض کنید ما یک سیستم بزرگ داریم که با حجم مناسبی از داده ها سر و کار داریم ( منظورم بیگ دیتا نیست) و نیاز داریم که داده ها رو در دیتابیس های مختلفی ذخیره کنیم به جای این که یک سرور دیتابیس داشته باشیم و صفر تا صد رو داخل اون ذخیره کنیم.
اگر sql بدونید و با دیتابیس ها کار کرده باشید میدونید ما یک کلید داریم تحت عنوان primary key یا کلید اصلی. که معمولا یا یک مقدار منحصر به فرد مثل کد ملی داره و یا این که auto increment هست ( یعنی کلید هر ردیف رو به شکل اتوماتیک ست میکنه : ۱و۳و۵و... که تو این مثال کلید ها دو تا دوتا اضافه شدن).
ویژگی auto increment مزیت هایی داره :
یک ) مطمئن هستیم که هیچوقت کلید تکراری در یک دیتابیس تولید نمیشه.
دو) کلید ها از الگوی خاصی پیروی میکنن که این هم میتونه مزیت و هم عیب محسوب بشه.
اما این روش اشکالاتی هم داره. زمانی که شما میخواید از معماری توزیع شده استفاده کنید قطعا بیش از یک دیتابیس دارید. مثلا دو تا یا سه تا. و هر کدوم از این دیتابیس ها نمیتونن با یک الگوی خاص داده رو ذخیره کنن.( اینطوری کلید تکراری میخوریم و مشکل بزرگ ایجاد میشه برامون)
و اما راه حل چیه؟
راه حل اول : از الگو های متفاوتی استفاده کنیم برا auto increment به عنوان مثال در دیتابیس A و B مثال های زیر رو ببینین
A : 1,3,5,7,...
B: 2,4,6,8,...
به نظر راه حل خوبی میاد ولی چند اشکال داره:
۱.مقیاس پذیری دشوار
۲.اگر سروری کم و زیاد بشه مقیاس پذیری ما به F**k میره :)
این یه مقدمه ای بود راجع به این چالشی که این روزا زیاد باهاش دست و پنجه نرم میکنیم. تو قسمت بعدی به ارائه روش های مناسبتری برای حل این چالش میپردازیم
سلام دوستان عزیز امیدوارم که حالتون خوب باشه. در کنارتون هستیم با یکی از پرکاربرد ترین و مهمترین مسئله های حوزه مهندسی نرم افزار و در حیطه سیستم های توزیع شده.
ما در قسمت قبل کمی درباره سیستم های توزیع شده و همینطور sharding صحبت کردیم و یه دید کلی نسبت بهش به دست آوردیم.
فرض کنید ما یک سیستم بزرگ داریم که با حجم مناسبی از داده ها سر و کار داریم ( منظورم بیگ دیتا نیست) و نیاز داریم که داده ها رو در دیتابیس های مختلفی ذخیره کنیم به جای این که یک سرور دیتابیس داشته باشیم و صفر تا صد رو داخل اون ذخیره کنیم.
اگر sql بدونید و با دیتابیس ها کار کرده باشید میدونید ما یک کلید داریم تحت عنوان primary key یا کلید اصلی. که معمولا یا یک مقدار منحصر به فرد مثل کد ملی داره و یا این که auto increment هست ( یعنی کلید هر ردیف رو به شکل اتوماتیک ست میکنه : ۱و۳و۵و... که تو این مثال کلید ها دو تا دوتا اضافه شدن).
ویژگی auto increment مزیت هایی داره :
یک ) مطمئن هستیم که هیچوقت کلید تکراری در یک دیتابیس تولید نمیشه.
دو) کلید ها از الگوی خاصی پیروی میکنن که این هم میتونه مزیت و هم عیب محسوب بشه.
اما این روش اشکالاتی هم داره. زمانی که شما میخواید از معماری توزیع شده استفاده کنید قطعا بیش از یک دیتابیس دارید. مثلا دو تا یا سه تا. و هر کدوم از این دیتابیس ها نمیتونن با یک الگوی خاص داده رو ذخیره کنن.( اینطوری کلید تکراری میخوریم و مشکل بزرگ ایجاد میشه برامون)
و اما راه حل چیه؟
راه حل اول : از الگو های متفاوتی استفاده کنیم برا auto increment به عنوان مثال در دیتابیس A و B مثال های زیر رو ببینین
A : 1,3,5,7,...
B: 2,4,6,8,...
به نظر راه حل خوبی میاد ولی چند اشکال داره:
۱.مقیاس پذیری دشوار
۲.اگر سروری کم و زیاد بشه مقیاس پذیری ما به F**k میره :)
این یه مقدمه ای بود راجع به این چالشی که این روزا زیاد باهاش دست و پنجه نرم میکنیم. تو قسمت بعدی به ارائه روش های مناسبتری برای حل این چالش میپردازیم
Forwarded from یادگیری ماشین با چاشنی صنعت (Abolfazl 🤘)
ساخت ID های منحصر به فرد در دیتابیس های توزیع شده ( قسمت دوم)
سلام دوستان امیدوارم که حالتون خوب باشه. این بار میخوایم قسمت قبل رو که یه مقدمه ای بود درباره دیتابیس های توزیع شده ادامه بدیم و یکم عمیق تر موضوع رو بررسی کنیم پس با ما همراه باشید.
راه حل بعدی که برای توزیع کلید ها بررسی میکنیم اسمش هست UUID
قطعا اگر توسعه پشت-انتها ( همون بک اند خودمونه) رو کار کرده باشید حداقل یکبار اسم UUID به گوشتون خورده. به یه شکل کلی بخوام توضیحش بدم میاد یه کلیدی که احتمال منحصر به فرد بودنش خیلی بالاست رو تولید میکنه و تو فیلد primary key دیتابیس قرار میده ( ۱۲۸ بیت هست) از قابل اعتماد بودن این روش همینقد اشاره کنم که اگر صد سال شما هر ثانیه یک کلید generate کنید، تازه احتمال تولید کلید تکراری به ۵۰ درصد میرسه. جالب نیست؟
این یه نمونه از UUID هست :09c93e62-50b4-468d-bf8a-c07e1040bfb2.
اینطوری با خیال راحت میتونید کلید های منحصر به فرد رو بین سرور های مختلف پخش کنید بدون هیچگونه نگرانی از تولید کلید های مشابه.
در واقع اینطور بگم که شما اگر پروژه بک اندتون رو روی چند سرور ران کنید، هر کدوم از سرور ها هر بار که نیاز شه یک کلید مجزا تولید میکنن بدون مشکل.
مشخصه که مشکلات مقیاس پذیری میاد پایین و این روش واقعا ساده و کم هزینست.
از معایبش هم اینه ۱۲۸ بیت رو رزرو میکنه در حالی که ما ۶۴ بیت فقط نیاز داریم و این که کلید تولیدی تنها عدد نیست ( البته عیب بزرگی محسوب نمیشن)
سلام دوستان امیدوارم که حالتون خوب باشه. این بار میخوایم قسمت قبل رو که یه مقدمه ای بود درباره دیتابیس های توزیع شده ادامه بدیم و یکم عمیق تر موضوع رو بررسی کنیم پس با ما همراه باشید.
راه حل بعدی که برای توزیع کلید ها بررسی میکنیم اسمش هست UUID
قطعا اگر توسعه پشت-انتها ( همون بک اند خودمونه) رو کار کرده باشید حداقل یکبار اسم UUID به گوشتون خورده. به یه شکل کلی بخوام توضیحش بدم میاد یه کلیدی که احتمال منحصر به فرد بودنش خیلی بالاست رو تولید میکنه و تو فیلد primary key دیتابیس قرار میده ( ۱۲۸ بیت هست) از قابل اعتماد بودن این روش همینقد اشاره کنم که اگر صد سال شما هر ثانیه یک کلید generate کنید، تازه احتمال تولید کلید تکراری به ۵۰ درصد میرسه. جالب نیست؟
این یه نمونه از UUID هست :09c93e62-50b4-468d-bf8a-c07e1040bfb2.
اینطوری با خیال راحت میتونید کلید های منحصر به فرد رو بین سرور های مختلف پخش کنید بدون هیچگونه نگرانی از تولید کلید های مشابه.
در واقع اینطور بگم که شما اگر پروژه بک اندتون رو روی چند سرور ران کنید، هر کدوم از سرور ها هر بار که نیاز شه یک کلید مجزا تولید میکنن بدون مشکل.
مشخصه که مشکلات مقیاس پذیری میاد پایین و این روش واقعا ساده و کم هزینست.
از معایبش هم اینه ۱۲۸ بیت رو رزرو میکنه در حالی که ما ۶۴ بیت فقط نیاز داریم و این که کلید تولیدی تنها عدد نیست ( البته عیب بزرگی محسوب نمیشن)
👍2
Forwarded from Python BackendHub
یکی از مشکلاتی که اکثر برنامه نویسا دارن تو مدیریت دپندسیه! حالا لایبری جدید یا external service که قراره ازش استفاده کنن.
مشکل چیه؟برنامه نویس میاد یک توتوریال از اون دپندسی جدید میبینه با خودش میگه ایول چه باحاله و تصمیم میگیره اضافش کنه! و این بد ترین کاریه که میتونید بکنید. قراره وابسته بشین به چیزی. فکر کنید این وابستگی از جنس عاطفیه. همینقدر باید باهاش حساس برخورد کنید :))
خب چیکار کنیم؟
اولین کاری که میکنید اینه که توتوریالشو میریزین دور. میرین داکیومنتشو خوب میخونید. متوجه میشین limitation هاش چیه. متوجه میشین سیستمش چطور کار میکنه. یک داکیومنت مختصر شده ازش میسازین و cons pro هاشو در میارین. مثلا یعنی چی؟
فکر کنید مثلا دارین یک external system اضافه میکنید. مثلا یک CRM. خب اول باید چک کنید چه limitation هایی داره؟ایا api داره؟ایا web hook داره؟ ایا share state به وجود میاد؟ هزینش چقدره؟ alternative هاش چیه؟ چطور اصلا کار میکنه؟ اصلا خوب کار میکنه؟!
بعد تو درجه دوم میرین گوگل میکنید و مقاله هایی پیدا میکنید که نقاط ضعفشو بیشتر گفته. ممکنه همه نقاط ضعفش تو داکیومنتش نباشه و یکم پنهان باشه. میبینید بقیه چه چالش هایی داشتن موقع کار کردن باهاش.
در نهایت بین آپشن ها یک لیست pro cons میسازین و تصمیم گیری نهایی رو میکنید.
اگه این کارو نکنیم چه اتفاقی میفته؟
بذارین مثال بگم. مثلا شما ندیدین این api limit احمقانه ای داره. بعد کلی روش کد میزنید. یک روزی سایز بیزنستون بزرگ تر میشه و حالا هرچی کد رو زدین باید undo کنید.
همیشه تو انتخاب دپندسی هاتون خیلی فکر کنید! من بعضا دیدم بچه ها میگن <کارفرما اینطوری گفته> یا <مدیر تیم با این بیشتر حال کرده>. اینا دلایل منطقی اصلا نیستن برای انتخاب یک دپندسی.
@ManiFoldsPython
مشکل چیه؟برنامه نویس میاد یک توتوریال از اون دپندسی جدید میبینه با خودش میگه ایول چه باحاله و تصمیم میگیره اضافش کنه! و این بد ترین کاریه که میتونید بکنید. قراره وابسته بشین به چیزی. فکر کنید این وابستگی از جنس عاطفیه. همینقدر باید باهاش حساس برخورد کنید :))
خب چیکار کنیم؟
اولین کاری که میکنید اینه که توتوریالشو میریزین دور. میرین داکیومنتشو خوب میخونید. متوجه میشین limitation هاش چیه. متوجه میشین سیستمش چطور کار میکنه. یک داکیومنت مختصر شده ازش میسازین و cons pro هاشو در میارین. مثلا یعنی چی؟
فکر کنید مثلا دارین یک external system اضافه میکنید. مثلا یک CRM. خب اول باید چک کنید چه limitation هایی داره؟ایا api داره؟ایا web hook داره؟ ایا share state به وجود میاد؟ هزینش چقدره؟ alternative هاش چیه؟ چطور اصلا کار میکنه؟ اصلا خوب کار میکنه؟!
بعد تو درجه دوم میرین گوگل میکنید و مقاله هایی پیدا میکنید که نقاط ضعفشو بیشتر گفته. ممکنه همه نقاط ضعفش تو داکیومنتش نباشه و یکم پنهان باشه. میبینید بقیه چه چالش هایی داشتن موقع کار کردن باهاش.
در نهایت بین آپشن ها یک لیست pro cons میسازین و تصمیم گیری نهایی رو میکنید.
اگه این کارو نکنیم چه اتفاقی میفته؟
بذارین مثال بگم. مثلا شما ندیدین این api limit احمقانه ای داره. بعد کلی روش کد میزنید. یک روزی سایز بیزنستون بزرگ تر میشه و حالا هرچی کد رو زدین باید undo کنید.
همیشه تو انتخاب دپندسی هاتون خیلی فکر کنید! من بعضا دیدم بچه ها میگن <کارفرما اینطوری گفته> یا <مدیر تیم با این بیشتر حال کرده>. اینا دلایل منطقی اصلا نیستن برای انتخاب یک دپندسی.
@ManiFoldsPython
👍7🥱1
Forwarded from CodeCrafters (مجتبی)
یکی از مهم ترین بخش های زبان کوئری نویسی SQL قسمت WHERE JOIN هست از هر دو میتوان برای کوئری زدن روی دو و یا چند جدول استفاده کرد اما تفاوت هایی با هم خواهند داشت با ذکر یک مثال این مورد را بیشتر توضیح میدهیم.
دو جدول فرضی را در نظر بگیرید
۱. جدول User با مقادیر Id, user_name , phone_number
۲.جدول Book با مقادیر Id, name, price, phone_number
(در واقعیت جدول Book به جدول User با کلید خارجی متصل میشود ولی در این مثال از این مورد چشم پوشی شده است )
اگر بخواهیم با استفاده از WHERE اطلاعات این دو جدول را بر اساس شرط phone_number با هم ترکیب کنیم، می‌توانیم از کوئری زیر استفاده کنیم:
SELECT *
FROM User, Book
WHERE User.phone_number = Book.phone_number;
این کوئری تمام رکوردهایی را انتخاب میکند که مقدار phone_number آنها در هر دو جدول یکسان است.
همچنین، می‌توانیم با استفاده از JOIN اطلاعات این دو جدول را بر اساس شرط phone_number با هم ترکیب کنیم. این مثال را با استفاده از JOIN به صورت زیر توسعه میدهیم:
SELECT *
FROM User
JOIN Book ON User.phone_number = Book.phone_number;
این کوئری نیز تمام رکوردهایی را انتخاب میکند که مقدار phone_number آنها در هر دو جدول یکسان است. با استفاده از JOIN، ما رکوردهای مشابه را از دو جدول به هم متصل میکنیم تا نتایج را بدست آوریم.
تفاوت اصلی در استفاده از WHERE و JOIN در این مثال، در نحوه نوشتن کوئری است. استفاده از JOIN به صورت مستقیم تر و خواناتر است و به طور ضمنی بهینه‌ترین روش اتصال دو جدول را انتخاب میکند. همچنین، استفاده از JOIN معمولاً در کوئری‌های پیچیده‌تر و وابستگی‌های بیشتر بین جداول مفیدتر است، زیرا به شما امکان اتصال جدول‌ها بر اساس شرایط مشترک را می‌دهد و نتایج را به صورت یکپارچه‌تر و منظم‌تر برگرداند.
#SQL
@code_crafters
دو جدول فرضی را در نظر بگیرید
۱. جدول User با مقادیر Id, user_name , phone_number
۲.جدول Book با مقادیر Id, name, price, phone_number
(در واقعیت جدول Book به جدول User با کلید خارجی متصل میشود ولی در این مثال از این مورد چشم پوشی شده است )
اگر بخواهیم با استفاده از WHERE اطلاعات این دو جدول را بر اساس شرط phone_number با هم ترکیب کنیم، می‌توانیم از کوئری زیر استفاده کنیم:
SELECT *
FROM User, Book
WHERE User.phone_number = Book.phone_number;
این کوئری تمام رکوردهایی را انتخاب میکند که مقدار phone_number آنها در هر دو جدول یکسان است.
همچنین، می‌توانیم با استفاده از JOIN اطلاعات این دو جدول را بر اساس شرط phone_number با هم ترکیب کنیم. این مثال را با استفاده از JOIN به صورت زیر توسعه میدهیم:
SELECT *
FROM User
JOIN Book ON User.phone_number = Book.phone_number;
این کوئری نیز تمام رکوردهایی را انتخاب میکند که مقدار phone_number آنها در هر دو جدول یکسان است. با استفاده از JOIN، ما رکوردهای مشابه را از دو جدول به هم متصل میکنیم تا نتایج را بدست آوریم.
تفاوت اصلی در استفاده از WHERE و JOIN در این مثال، در نحوه نوشتن کوئری است. استفاده از JOIN به صورت مستقیم تر و خواناتر است و به طور ضمنی بهینه‌ترین روش اتصال دو جدول را انتخاب میکند. همچنین، استفاده از JOIN معمولاً در کوئری‌های پیچیده‌تر و وابستگی‌های بیشتر بین جداول مفیدتر است، زیرا به شما امکان اتصال جدول‌ها بر اساس شرایط مشترک را می‌دهد و نتایج را به صورت یکپارچه‌تر و منظم‌تر برگرداند.
#SQL
@code_crafters
❤5👍1
Forwarded from Python BackendHub
این مقاله که دیروز معرفی کردم یادتونه؟
یک سر رفتم تو سایتش
چقدر مطالب خوب داره راجب پایتون
و مخصوصا تایپینگ 👌
برای چیزای مربوط به تایپینگ:
https://adamj.eu/tech/tag/mypy/
برای پایتون به صورت کلی:
https://adamj.eu/tech/tag/python/
یک سر بزنید حتما 👌
@ManiFoldsPython
یک سر رفتم تو سایتش
چقدر مطالب خوب داره راجب پایتون
و مخصوصا تایپینگ 👌
برای چیزای مربوط به تایپینگ:
https://adamj.eu/tech/tag/mypy/
برای پایتون به صورت کلی:
https://adamj.eu/tech/tag/python/
یک سر بزنید حتما 👌
@ManiFoldsPython
👍7
Forwarded from Microfrontend.ir
اگر برنامه نویس جنگو هستید حتما استفاده از select_related و prefetch_related رو تو کوییری ست هاتون مد نظر داشته باشید. دیروز با دوستی سرویسی رو چک میکردیم که کار سنگینی رو انجام و میداد و بیش از ۸۰ ثانیه رو یک سیستم نسبتا قوی طول میکشید، صرفا با اضافه کردن مواردی که گفتم تایم اجرا اومد رو ۵ ثانیه
بهینه سازی جنگو از طریق select_related
Link: https://youtu.be/TK3P4Cy5fNg
بهینه سازی جنگو از طریق prefetch_related
Link: https://youtu.be/lkThOygE8LM
بهینه سازی جنگو از طریق defer و only
Link: https://youtu.be/u629fDW5drM
پلی لیست نکته ها و ترفندهای جنگو:
https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
بهینه سازی جنگو از طریق select_related
Link: https://youtu.be/TK3P4Cy5fNg
بهینه سازی جنگو از طریق prefetch_related
Link: https://youtu.be/lkThOygE8LM
بهینه سازی جنگو از طریق defer و only
Link: https://youtu.be/u629fDW5drM
پلی لیست نکته ها و ترفندهای جنگو:
https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv
〰️〰️〰️〰️〰️〰️
© @microfrontend_ir
YouTube
مصاحبه فنی جنگو Django ORM : select_related
در اغلب مصاحبه های فنی جنگو سوال کاربرد select_related پرسیده میشود با این وجو اغلب اهمیت این فانکشن نادیده گرفته می شود. عدم استفاده ویژگی مهم select_related در Django ORM میتواند تاثیر منفی سنگینی در اپلیکیشن داشته باشد. در این ویدیو با یک مثال ساده…
👍6
Forwarded from a pessimistic researcher (Kc)
"برنامه‌نویسی با طعم شیرین اثبات"
———————————————
یکی از آرزوهام اینه که اگر یه روزی استاد دانشگاه شدم، یکی از دروسی که حتما درس بدمش درس مبانی برنامه‌نویسی باشه. به‌نظرم یکی از مناسب‌ترین جاها برای اینکه بشه به یک ذهنی ساختار و شکل داد، زمانیه که ذهن خالی از هرگونه دیدگاه و اندیشه‌ی خام و نارس باشه. یعنی همون اول کار ذهن طرف جوری شکل بگیره که تا آخر عمر دعات کنه. جای اینکه ذهنش پر بشه از کلی سینتکس و پارادایم‌هایی که براش کلی تناقض و بی ثباتی ایجاد میکنه، ذهنش رو سازماندهی کنی تا نظمی مستحکم استوار بشه. خلاصه خوابای زیادی دیدم برای اون روز :)))
قطع به یقین سیلابس اون درس، برپایه‌ی Curry–Howard isomorphism خواهد بود، بدون اینکه دانشجوها متوجه این قضیه بشن یا دردی احساس کنن :))) ممکنه بپرسید چرا چنین تصمیمی دارم و اصلا این چیزی که گفتم بدون درد و خون‌ریزی معنیش چیه.
بذارید کمک‌تون کنم. آقای Haskell Brooks Curry که به احترام ایشون، زبان برنامه‌نویسی Haskell، زبان برنامه نویسی Curry و زبان برنامه‌نویسی Brooks رو از روی نام ایشون انتخاب کردند، به همراه آقای Wiliam Howard یک رابطه‌ای کشف کردند که به Curry–Howard isomorphism معروفه. این رابطه به زبان ساده میگه که بین logic و programming، بین Proof و Program و بین Theorems و Types یک نوع Isomorphism وجود داره. یعنی هر Type یک Theorem و هر برنامه یک اثبات هستش. حالت معوکسش هم برقراره یعنی هر اثبات یک برنامه است. طبق این رابطه، میشه اثبات کرد زمانی که شما برای هر زبان برنامه‌نویسی که از نوع statically typed یا dependent type باشه(یعنی Type ای که وابسه به Value باشه)، یک Type Checker بسازید، در اصل براش یک Theorem Prover ساختید! بنابراین میشه برنامه‌هایی که با این زبان‌ها نوشته میشن رو طبق Curry–Howard isomorphism به یک اثبات تبدیل کرد و این به ما کمک میکنه که بتونیم درستی برنامه‌ای که نوشتیم رو اثبات کنیم.
حالا شاید براتون کم کم ملموس شده باشه که چرا میخوام چنین کاری بکنم. میام بهشون یه زبان Functional Dependent Type یاد میدم مثل Agda، Coq یا Idris که هم برنامه‌نویسی فرمال بر اساس Lambda Calculus که یک Universal Computation Model مثل ماشین تورینگ هست رو یاد بگیرن و هم بتونن با استفاده از Theorem Proving، درستی برنامه‌ای که نوشتن رو اثبات کنن.
حالا اصلا چرا این همه براتون حرف زدم و سرتون رو درد آوردم؟
چون همین چند روز پیش متوجه شدم که تفکر بنده رو قبلا بهش رسیدن و یه پارادایم برنامه‌نویسی بر اساسش توسعه دادن به نام Proof-Oriented Programming. یعنی همون موقعی که داری Program ات رو Design میکنی، اثبات درستیش رو هم جلو ببری.
هم پیمان با این پاردایم، زبان برنامه‌نویسی ای توسعه داده شده که هم Dependent Type Functional Programming هستش و هم با استفاده از Z3 که یک Theorem Prover هستش که برا اساس SMT-Solving کار میکنه، میتونیم برنامه‌هایی که باهاش می‌نویسیم رو اثبات کنیم. این زبان F* نام داره و اولین بار در سال ۲۰۱۱ توسط تیم Prosecco در موسسه‌ی INRIA Paris توسعه داده شد. بعدها Microsoft خیلی از این زبان خوشش اومد و پروژه توسط تیم Prosecco و Microsoft Research در سال ۲۰۱۶ بازنویسی شد و ورژن فعلی زبان F* بر اساس همون پیپر ۲۰۱۶ هستش. سینتکس زبان شبیه به ML هستش(یقینا منظورم اون ML دروغین که توی ذهن همه‌تونه نیست :))) ).
برنامه‌های F* به طور معمول به زبان OCaml کامپایل و اجرا میشن. البته یک سری Fragment از زبان F* هم هستن که به C و Assembly کامپیال میشن مثل Low* که یک فرگمنت از زبان F* هستش.
شما به واسطه‌ی F* میتونید برنامه‌ای که می‌نویسید رو از چند جهت Verify کنید. یکیش اینه که برنامه از نظر Functionality داره درست کار میکنه که این میشه همون اثبات Correctness. بحث بعدی ویژگی‌های امنیتی به طور مثال اثبات کنید که برنامه‌تون هیچ وقت دیتا secrete رو Leak نمی‌کنه. و بحث آخر هم اثبات Lower bound و Upper Bound روی منابعی که مصرف میکنه.
اگر میخواید F* یاد بگیرید چند تا راه وجود داره. کتابی برای این زبان نوشته شده که به‌طور رایگان در دسترس عموم قرار داره و میتونید فایل PDF اش رو از اینجا دانلود کنید. از طریق این لینک هم میتونید به صورت Web-based این کتاب رو بخونید. خوبیشم اینه که همواره آپدیت میشه.
تعدادی هم مینی کورس بر اساس این زبان ساخته شده میتونید توی صفحه‌ی اصلی زبان، توی بخش Course Material به منابع این کورس ها اعم از Lecture Notes ها و کدها دسترسی پیدا کنید.
———————————————
یکی از آرزوهام اینه که اگر یه روزی استاد دانشگاه شدم، یکی از دروسی که حتما درس بدمش درس مبانی برنامه‌نویسی باشه. به‌نظرم یکی از مناسب‌ترین جاها برای اینکه بشه به یک ذهنی ساختار و شکل داد، زمانیه که ذهن خالی از هرگونه دیدگاه و اندیشه‌ی خام و نارس باشه. یعنی همون اول کار ذهن طرف جوری شکل بگیره که تا آخر عمر دعات کنه. جای اینکه ذهنش پر بشه از کلی سینتکس و پارادایم‌هایی که براش کلی تناقض و بی ثباتی ایجاد میکنه، ذهنش رو سازماندهی کنی تا نظمی مستحکم استوار بشه. خلاصه خوابای زیادی دیدم برای اون روز :)))
قطع به یقین سیلابس اون درس، برپایه‌ی Curry–Howard isomorphism خواهد بود، بدون اینکه دانشجوها متوجه این قضیه بشن یا دردی احساس کنن :))) ممکنه بپرسید چرا چنین تصمیمی دارم و اصلا این چیزی که گفتم بدون درد و خون‌ریزی معنیش چیه.
بذارید کمک‌تون کنم. آقای Haskell Brooks Curry که به احترام ایشون، زبان برنامه‌نویسی Haskell، زبان برنامه نویسی Curry و زبان برنامه‌نویسی Brooks رو از روی نام ایشون انتخاب کردند، به همراه آقای Wiliam Howard یک رابطه‌ای کشف کردند که به Curry–Howard isomorphism معروفه. این رابطه به زبان ساده میگه که بین logic و programming، بین Proof و Program و بین Theorems و Types یک نوع Isomorphism وجود داره. یعنی هر Type یک Theorem و هر برنامه یک اثبات هستش. حالت معوکسش هم برقراره یعنی هر اثبات یک برنامه است. طبق این رابطه، میشه اثبات کرد زمانی که شما برای هر زبان برنامه‌نویسی که از نوع statically typed یا dependent type باشه(یعنی Type ای که وابسه به Value باشه)، یک Type Checker بسازید، در اصل براش یک Theorem Prover ساختید! بنابراین میشه برنامه‌هایی که با این زبان‌ها نوشته میشن رو طبق Curry–Howard isomorphism به یک اثبات تبدیل کرد و این به ما کمک میکنه که بتونیم درستی برنامه‌ای که نوشتیم رو اثبات کنیم.
حالا شاید براتون کم کم ملموس شده باشه که چرا میخوام چنین کاری بکنم. میام بهشون یه زبان Functional Dependent Type یاد میدم مثل Agda، Coq یا Idris که هم برنامه‌نویسی فرمال بر اساس Lambda Calculus که یک Universal Computation Model مثل ماشین تورینگ هست رو یاد بگیرن و هم بتونن با استفاده از Theorem Proving، درستی برنامه‌ای که نوشتن رو اثبات کنن.
حالا اصلا چرا این همه براتون حرف زدم و سرتون رو درد آوردم؟
چون همین چند روز پیش متوجه شدم که تفکر بنده رو قبلا بهش رسیدن و یه پارادایم برنامه‌نویسی بر اساسش توسعه دادن به نام Proof-Oriented Programming. یعنی همون موقعی که داری Program ات رو Design میکنی، اثبات درستیش رو هم جلو ببری.
هم پیمان با این پاردایم، زبان برنامه‌نویسی ای توسعه داده شده که هم Dependent Type Functional Programming هستش و هم با استفاده از Z3 که یک Theorem Prover هستش که برا اساس SMT-Solving کار میکنه، میتونیم برنامه‌هایی که باهاش می‌نویسیم رو اثبات کنیم. این زبان F* نام داره و اولین بار در سال ۲۰۱۱ توسط تیم Prosecco در موسسه‌ی INRIA Paris توسعه داده شد. بعدها Microsoft خیلی از این زبان خوشش اومد و پروژه توسط تیم Prosecco و Microsoft Research در سال ۲۰۱۶ بازنویسی شد و ورژن فعلی زبان F* بر اساس همون پیپر ۲۰۱۶ هستش. سینتکس زبان شبیه به ML هستش(یقینا منظورم اون ML دروغین که توی ذهن همه‌تونه نیست :))) ).
برنامه‌های F* به طور معمول به زبان OCaml کامپایل و اجرا میشن. البته یک سری Fragment از زبان F* هم هستن که به C و Assembly کامپیال میشن مثل Low* که یک فرگمنت از زبان F* هستش.
شما به واسطه‌ی F* میتونید برنامه‌ای که می‌نویسید رو از چند جهت Verify کنید. یکیش اینه که برنامه از نظر Functionality داره درست کار میکنه که این میشه همون اثبات Correctness. بحث بعدی ویژگی‌های امنیتی به طور مثال اثبات کنید که برنامه‌تون هیچ وقت دیتا secrete رو Leak نمی‌کنه. و بحث آخر هم اثبات Lower bound و Upper Bound روی منابعی که مصرف میکنه.
اگر میخواید F* یاد بگیرید چند تا راه وجود داره. کتابی برای این زبان نوشته شده که به‌طور رایگان در دسترس عموم قرار داره و میتونید فایل PDF اش رو از اینجا دانلود کنید. از طریق این لینک هم میتونید به صورت Web-based این کتاب رو بخونید. خوبیشم اینه که همواره آپدیت میشه.
تعدادی هم مینی کورس بر اساس این زبان ساخته شده میتونید توی صفحه‌ی اصلی زبان، توی بخش Course Material به منابع این کورس ها اعم از Lecture Notes ها و کدها دسترسی پیدا کنید.
👏5👍1
Forwarded from Syntax | سینتکس (Alireza-fa)
تو سالهای اخیر اغلب شرکت‌های نرم‌افزاری خارجی و داخلی به سنجش قدرت حل مساله افراد از طریق پرسیدن سوال‌های الگوریتمی روی آوردند که به نظر من بسیار رویکرد خوبی برای مصاحبه هست. شاید مهمترین دلیلش این باشه که بیشتر از تسلط به ابزارها و تکنولوژی‌ها و حتی زبان‌های برنامه‌نویسی یا چارچوب‌ها، قدرت حل مساله و ارائه راهکار مناسب برای مسائل و چالش‌های مختلف عیار یه مهندس نرم‌افزار خوب رو مشخص میکنه. البته این مدل مصاحبه‌ها بیشتر برای توسعه‌دهنده‌ها مرسومه. ولی چه کنیم که در این مدل مصاحبه‌ها خروجی بهتری داشته باشیم؟
۱- قبل از مصاحبه حداقل چند روزی رو صرف مطالعه یه کتاب تو این زمینه بکنید و بد هم نیست چند تا مساله توی سایت‌هایی مثل Codeforces یا LeetCode یا HackerRank بکنید. برای کتاب هم من دو تا پیشنهاد دارم:
- کتاب Cracking the coding interview
https://www.crackingthecodinginterview.com/
- کتاب Algorithms Notes for Professionals
https://lnkd.in/dcC74Uxs
۲- حتما در طول مصاحبه سعی کنید بلند بلند فکر کنید و در مورد ابعاد مختلف مساله از مصاحبه‌کننده توضیح بخواید. این به شما کمک میکنه که هم فرصت بیشتری برای فکر کردن داشته باشید و هم مسیر رو درست برید. کلاً هر چی بیشتر در طول مصاحبه تعامل بکنید مثبت‌تره.
۳- به یاد داشته باشید که برای یه مصاحبه‌کننده حرفه‌ای هدف از پرسیدن سوال‌های حل مساله بیشتر بررسی مدل فکر کردن شماست و خیلی مواقع حتی ممکنه رسیدن به جواب بهینه خیلی مهم نباشه. بنابراین حتما از ساده‌ترین راه‌حل ممکن شروع کنید و سعی کنید به مرور راه‌حل رو بهبود بدید. در زمان ارائه راه‌حل سیستماتیک فکر کردن و تعامل با مصاحبه‌کننده خیلی راهگشاست.
۴- معمولاً برای ارائه راه‌حل شما باید از یه زبان برنامه‌نویسی استفاده کنید و برخی مواقع مخصوصاً در مصاحبه‌های آنلاین ممکنه دسترسی به IDE نداشته باشید. بنابراین آماده این موضوع باشید. در زمان نوشتن سعی کنید کد رو تمیز و خوانا بنویسید چون معمولاً کیفیت کد روی نظر مصاحبه‌کننده تاثیر می‌ذاره.
پانوشت: پیرو کامنت بعضی از دوستان یه نکته اضافه کنم. ارزیابی توان حل مساله صرفاً بخشی از یه مصاحبه خوبه و نه تمامش و معمولاً سوالات خیلی سختی پرسیده نمیشه. برای یه نمونه سوال خوب، بد نیست ویدیو زیر رو ببینید که یه سوال ساده در مصاحبه شرکت گوگل هست:
https://www.youtube.com/watch?v=XKu_SEDAykw
Saeed Shahrivari Joghan
#note
@khat_academy
۱- قبل از مصاحبه حداقل چند روزی رو صرف مطالعه یه کتاب تو این زمینه بکنید و بد هم نیست چند تا مساله توی سایت‌هایی مثل Codeforces یا LeetCode یا HackerRank بکنید. برای کتاب هم من دو تا پیشنهاد دارم:
- کتاب Cracking the coding interview
https://www.crackingthecodinginterview.com/
- کتاب Algorithms Notes for Professionals
https://lnkd.in/dcC74Uxs
۲- حتما در طول مصاحبه سعی کنید بلند بلند فکر کنید و در مورد ابعاد مختلف مساله از مصاحبه‌کننده توضیح بخواید. این به شما کمک میکنه که هم فرصت بیشتری برای فکر کردن داشته باشید و هم مسیر رو درست برید. کلاً هر چی بیشتر در طول مصاحبه تعامل بکنید مثبت‌تره.
۳- به یاد داشته باشید که برای یه مصاحبه‌کننده حرفه‌ای هدف از پرسیدن سوال‌های حل مساله بیشتر بررسی مدل فکر کردن شماست و خیلی مواقع حتی ممکنه رسیدن به جواب بهینه خیلی مهم نباشه. بنابراین حتما از ساده‌ترین راه‌حل ممکن شروع کنید و سعی کنید به مرور راه‌حل رو بهبود بدید. در زمان ارائه راه‌حل سیستماتیک فکر کردن و تعامل با مصاحبه‌کننده خیلی راهگشاست.
۴- معمولاً برای ارائه راه‌حل شما باید از یه زبان برنامه‌نویسی استفاده کنید و برخی مواقع مخصوصاً در مصاحبه‌های آنلاین ممکنه دسترسی به IDE نداشته باشید. بنابراین آماده این موضوع باشید. در زمان نوشتن سعی کنید کد رو تمیز و خوانا بنویسید چون معمولاً کیفیت کد روی نظر مصاحبه‌کننده تاثیر می‌ذاره.
پانوشت: پیرو کامنت بعضی از دوستان یه نکته اضافه کنم. ارزیابی توان حل مساله صرفاً بخشی از یه مصاحبه خوبه و نه تمامش و معمولاً سوالات خیلی سختی پرسیده نمیشه. برای یه نمونه سوال خوب، بد نیست ویدیو زیر رو ببینید که یه سوال ساده در مصاحبه شرکت گوگل هست:
https://www.youtube.com/watch?v=XKu_SEDAykw
Saeed Shahrivari Joghan
#note
@khat_academy
🔥5👍3
✅ مطلبی از لینکدین Saeed Shahrivari Joghan
لینک پست در کامنت
سری مهندسی نرم‌افزار: پست1
اولین پست سری مهندسی نرم‌افزار رو با تعریف خود نرم‌افزار شروع میکنم. شاید در نگاه اول تعریف نرم‌افزار برای اغلب افراد کامپیوتری خیلی بدیهی باشه اما بد نیست همین الان بهش فکر کنیم که تعریف نرم‌افزار چیه؟ اغلب بنا به تجربه من تعریفش سخته، چون بدیهیه!
تعاریفی که معمولا من شنیدم یه چیزایی مثل این عباراته:
- مجموعه‌ای از کدهای قابل اجرا توسط کامپیوتر
- هر چیزی به جز سخت‌افزار که باعث اجرای فرمانهای انسان رو ماشین بشه
شاید این تعاریف به صورت حسی و شهودی بد نباشن ولی یه مشکل توی این تعاریف وجود داره و اون هم گم بودن حدود نرم‌افزار در یک سیستمه. طبق تعریف کلاسیک «نرم‌افزار مجموعه‌ای از دستورالعمل‌های قابل اجرا توسط کامپیوتر (یا به عبارتی برنامه) در کنار داده‌ها و مستندات مربوطه است». معمولا طبق این تعریف دو چیز در تعریف نرم‌افزار مغفول می‌مونه اولی مفهوم داده هست و دومی مستندات. اگه به تعریف دقت کنیم نرم‌افزار صرفا کد نیست و داده و مستندات جزیی از نرم‌افزار هستن که دقیقا مثل کد شهروند درجه یک محسوب میشن بنابراین باید برای توسعه و نگهداری داده و مستندات ما فرآیند‌های مهندسی شده داشته باشیم.
به عبارتی اگه فردی در یک شرکت صرفا مسئول نگارش و نگهداری مستندات باشه همچنان مهندس نرم‌افزار محسوب میشه یا اگه کسی تحلیل‌گر باشه و خروجی کارش بشه اسناد تحلیلی باز هم یه مهندس نرم‌افزار محسوب میشه. به همین ترتیب افرادی که مسئولیت نگهداری پایگاه‌داده یا زیرساخت و چیزهایی از این دست رو دارند باز هم مهندس نرم‌افزار هستند.
ما نباید در نرم‌افزار فقط کد رو شهروند درجه یک بدونیم و در کنارش برای داده و مستندات هم باید حساسیت نشون بدیم یعنی برای توسعه و نگهداری اونها باید فرآیند‌های درست و کارآمد داشته باشیم. برای مثال باید به این برسیم که پایگاه‌دانش در یک شرکت به اندازه مخزن کد اهمیت داره چون مستندات جزیی از نرم‌افزاره پس باید براش وقت و انرژی صرف کرد.
برای اینکه این اصل رو همیشه به ذهن بسپریم میشه همچین معادله ساده‌ای رو داشت:
نرم‌افزار = کد + داده + مستندات
هم‌نظر شدن روی همین تعریف ساده در بسیاری از مسائل مثل اولویت‌بندی کارها و بودجه‌بندی و حتی تصمیمات فنی میتونه راهگشا باشه. برای اطلاعات بیشتر مثل انواع نرم‌افزار و حوزه‌های کاربردی نرم‌افزار، میتونید به فصل اول کتاب پرسمن یا فصل اول کتاب سامرویل مراجعه کنید. متاسفانه لینکدین اجازه گذاشتن لینک نمیده پس لطفا خودتون سرچ کنید. لطفا اگه نظر یا سوالی در این زمینه دارید زیر این پست کامنت کنید و همچنین از هر پیشنهاد و انتقادی برای بهبود ارائه مطالب استقبال میکنم.
عناوین کتاب‌ها:
Software Engineering: A Practitioner's Approach, Pressman
Software Engineering, Sommerville
لینک پست در کامنت
سری مهندسی نرم‌افزار: پست1
اولین پست سری مهندسی نرم‌افزار رو با تعریف خود نرم‌افزار شروع میکنم. شاید در نگاه اول تعریف نرم‌افزار برای اغلب افراد کامپیوتری خیلی بدیهی باشه اما بد نیست همین الان بهش فکر کنیم که تعریف نرم‌افزار چیه؟ اغلب بنا به تجربه من تعریفش سخته، چون بدیهیه!
تعاریفی که معمولا من شنیدم یه چیزایی مثل این عباراته:
- مجموعه‌ای از کدهای قابل اجرا توسط کامپیوتر
- هر چیزی به جز سخت‌افزار که باعث اجرای فرمانهای انسان رو ماشین بشه
شاید این تعاریف به صورت حسی و شهودی بد نباشن ولی یه مشکل توی این تعاریف وجود داره و اون هم گم بودن حدود نرم‌افزار در یک سیستمه. طبق تعریف کلاسیک «نرم‌افزار مجموعه‌ای از دستورالعمل‌های قابل اجرا توسط کامپیوتر (یا به عبارتی برنامه) در کنار داده‌ها و مستندات مربوطه است». معمولا طبق این تعریف دو چیز در تعریف نرم‌افزار مغفول می‌مونه اولی مفهوم داده هست و دومی مستندات. اگه به تعریف دقت کنیم نرم‌افزار صرفا کد نیست و داده و مستندات جزیی از نرم‌افزار هستن که دقیقا مثل کد شهروند درجه یک محسوب میشن بنابراین باید برای توسعه و نگهداری داده و مستندات ما فرآیند‌های مهندسی شده داشته باشیم.
به عبارتی اگه فردی در یک شرکت صرفا مسئول نگارش و نگهداری مستندات باشه همچنان مهندس نرم‌افزار محسوب میشه یا اگه کسی تحلیل‌گر باشه و خروجی کارش بشه اسناد تحلیلی باز هم یه مهندس نرم‌افزار محسوب میشه. به همین ترتیب افرادی که مسئولیت نگهداری پایگاه‌داده یا زیرساخت و چیزهایی از این دست رو دارند باز هم مهندس نرم‌افزار هستند.
ما نباید در نرم‌افزار فقط کد رو شهروند درجه یک بدونیم و در کنارش برای داده و مستندات هم باید حساسیت نشون بدیم یعنی برای توسعه و نگهداری اونها باید فرآیند‌های درست و کارآمد داشته باشیم. برای مثال باید به این برسیم که پایگاه‌دانش در یک شرکت به اندازه مخزن کد اهمیت داره چون مستندات جزیی از نرم‌افزاره پس باید براش وقت و انرژی صرف کرد.
برای اینکه این اصل رو همیشه به ذهن بسپریم میشه همچین معادله ساده‌ای رو داشت:
نرم‌افزار = کد + داده + مستندات
هم‌نظر شدن روی همین تعریف ساده در بسیاری از مسائل مثل اولویت‌بندی کارها و بودجه‌بندی و حتی تصمیمات فنی میتونه راهگشا باشه. برای اطلاعات بیشتر مثل انواع نرم‌افزار و حوزه‌های کاربردی نرم‌افزار، میتونید به فصل اول کتاب پرسمن یا فصل اول کتاب سامرویل مراجعه کنید. متاسفانه لینکدین اجازه گذاشتن لینک نمیده پس لطفا خودتون سرچ کنید. لطفا اگه نظر یا سوالی در این زمینه دارید زیر این پست کامنت کنید و همچنین از هر پیشنهاد و انتقادی برای بهبود ارائه مطالب استقبال میکنم.
عناوین کتاب‌ها:
Software Engineering: A Practitioner's Approach, Pressman
Software Engineering, Sommerville
❤2👏1
Forwarded from Syntax | سینتکس (Alireza-fa)
درک traceback پایتون
مطالعه
توضیح:
در برنامه نویسی مفهومی به اسم stack trace و یا stack backtrace مطرح است.
بصورت خیلی مختصر کاری که انجام می دهد این است مسیر اجرای کد شمارا از نقطه شروع اجرای کد تا زمانی که به اتمام برسد را در استک ذخیره میکند. برای مثال زمانی که با یک exception مواجه میشوید شما می توانید مسیری که برنامه از آن عبور کرده تا به exception خورده را مشاهده کنید که این کار با کمک stack trace انجام میشود.
در پایتون شما زمانی که با یک exception مواجه میشوید پیغامی به اسم traceback و متنی طولانی نمایش داده میشود.
در این مقابله به خوبی توضیح داده شده که چگونه در این شرایط عمل کنید.
#note
@Syntax_fa
مطالعه
توضیح:
در برنامه نویسی مفهومی به اسم stack trace و یا stack backtrace مطرح است.
بصورت خیلی مختصر کاری که انجام می دهد این است مسیر اجرای کد شمارا از نقطه شروع اجرای کد تا زمانی که به اتمام برسد را در استک ذخیره میکند. برای مثال زمانی که با یک exception مواجه میشوید شما می توانید مسیری که برنامه از آن عبور کرده تا به exception خورده را مشاهده کنید که این کار با کمک stack trace انجام میشود.
در پایتون شما زمانی که با یک exception مواجه میشوید پیغامی به اسم traceback و متنی طولانی نمایش داده میشود.
در این مقابله به خوبی توضیح داده شده که چگونه در این شرایط عمل کنید.
#note
@Syntax_fa
❤2
✅ ساخت ID های منحصر به فرد (قسمت سوم) Ticket server
از کانال @Engineering_property
اگر پروژه شما خیلی بزرگ نباشه، یه راه جالب برای تولید primarykey های منحصر به فرد استفاده از تیکت سرور هست. در حقیقت سرور تیکت میاد و کلید هارو به شکل auto increment برای ما ایجاد میکنه بدون نگرانی از این که برای دوتا دیتا، کلید های یکسانی تولید شه ( در حقیقت تیکت سرور شما، میتونه سرور دیتابیس شما باشه)
اگر به شکل زیر توجه کنید، متوجه میشید که وب سرور های ما برای تولید کلید های منحصر به فرد دارن به تیکت سرور درخواست میزنن. فقط یه مشکلی اینجا هست به نام single point of failure یعنی اگر به هر دلیلی تیکت سرور ما بیاد پایین، بیچاره میشیم. برای حل این مشکل میتونیم چن تا تیکت سرور بذاریم که این هم خودش باز داستان داره و در این مقوله نمیگنجه.
این مبحث یه بخش چهارمی هم داره که به نظرم جالب میاد و احتمالا دربارش مطلب تهیه میکنم.
از کانال @Engineering_property
اگر پروژه شما خیلی بزرگ نباشه، یه راه جالب برای تولید primarykey های منحصر به فرد استفاده از تیکت سرور هست. در حقیقت سرور تیکت میاد و کلید هارو به شکل auto increment برای ما ایجاد میکنه بدون نگرانی از این که برای دوتا دیتا، کلید های یکسانی تولید شه ( در حقیقت تیکت سرور شما، میتونه سرور دیتابیس شما باشه)
اگر به شکل زیر توجه کنید، متوجه میشید که وب سرور های ما برای تولید کلید های منحصر به فرد دارن به تیکت سرور درخواست میزنن. فقط یه مشکلی اینجا هست به نام single point of failure یعنی اگر به هر دلیلی تیکت سرور ما بیاد پایین، بیچاره میشیم. برای حل این مشکل میتونیم چن تا تیکت سرور بذاریم که این هم خودش باز داستان داره و در این مقوله نمیگنجه.
این مبحث یه بخش چهارمی هم داره که به نظرم جالب میاد و احتمالا دربارش مطلب تهیه میکنم.
👍3
Forwarded from Python BackendHub
یک پست دوست داشتم بنویسم, راجب review کردن و نگه داری یک PR با بست پرکتیس هایی که باید رعایت شه
اولا study نشون داده که شما هرچقدر بیشتر وقت بذارین رو review کردن یک PR همونقدر پروداکتتون جلوتر میفته. یعنی چی؟ مگه میشه؟اره خب , شما هرچی زودتر جلوی باگو بگیری زمان کمتری براش صرف میکنی. قبل کد زدن بهترین موقع برای پیدا کردن باگه!(یک requirement خیلی خوشگل و تمیز). در درجه بعدی موقع کد زدن و فکر کردن به کدی که میزنید. در درجه بعدی موقع بررسی PR. در درجه بعدی رو dev و بعد رو staging و در نهایت رو پروداکشن. چرا اینو میگم؟چون مثلا اگه یک باگی پیدا کنیم که تو staging باشه ولی تو پروداکشن نباشه یعنی یکی از pr ها مشکل بوده. ولی مشکل که بره رو پروداکشن خیلی سخت تر میشه track اش کرد که دقیقا منشا اش کجا بوده و بیشتر طول میکشه چون پهنا بیشتری داره.
حالا سوال اینجاست چیکار کنیم موقع review؟ اولین کاری که میکنید اینه که requirement رو نگاه میکنید و تو ذهنتون آنالیز میکنید چه چیزایی نیازه. بعد رو کد میگردین دنبال edge case. ممکنه حتی تو requirement هم به edge case و باگ برسین! تا اینجا فقط باگای لاجیکاله. در درجه بعدی سعی میکنید تستا رو بخونید. اگه pr ای تست نداره, فیچری تست نداره بهتره اصلا مرج نشه. تستا رو که خوندین حتما کیس هایی هست که دستی باید تست شه حداقل یک بار. کیس هایی که شاید خیلی خوب نمیشد تست اتوماتیک نوشت براش. میرین و checkout میکنید و یک دور تست دستی هم انجام میدین. احتمال اینکه باگ پیدا کنید خیلی زیاد میشه اینطوری. و درنهایت میپردازین به مباحث دیزاین کد و پرفومنس اگه جایی مثلا نیاز به decoupling داشت یا جایی نیاز. بود یک queryبهینه تر نوشته شه.
با این فرمول اگه برین جلو اکثر مواقع PR به changes requested میخوره مخصوصا برای نیروی جدید. سعی کنید یک PR رو خیلی گنده نکنید چون review اش خیلی سخت تر میشه و احتمال پیدا کردن باگ کمتر.
یک مشکل دیگه که خیلیا انجام میدن اینه که داخل PR میان بیشتر از تایتلش انجام میدن. مثلا طبق git flow مشخصه یک PR چه چیزایی میتونه باشه. یک pr همزمان نباید هم یک issue رو درست کنه هم یک فیچر اضافه کنه. اگه وسط توسعه به اون issue رسیدین و شناساییش کردین باید یک برنچ جدا بسازین, اون ایشو رو اونجا درست کنید با تست فیل و cherry pick کنیدش رو برنچ فیچری که داشتین کار میکردین که جداگانه review شه و سریعتر مرج شه.
@ManiFoldsPython
اولا study نشون داده که شما هرچقدر بیشتر وقت بذارین رو review کردن یک PR همونقدر پروداکتتون جلوتر میفته. یعنی چی؟ مگه میشه؟اره خب , شما هرچی زودتر جلوی باگو بگیری زمان کمتری براش صرف میکنی. قبل کد زدن بهترین موقع برای پیدا کردن باگه!(یک requirement خیلی خوشگل و تمیز). در درجه بعدی موقع کد زدن و فکر کردن به کدی که میزنید. در درجه بعدی موقع بررسی PR. در درجه بعدی رو dev و بعد رو staging و در نهایت رو پروداکشن. چرا اینو میگم؟چون مثلا اگه یک باگی پیدا کنیم که تو staging باشه ولی تو پروداکشن نباشه یعنی یکی از pr ها مشکل بوده. ولی مشکل که بره رو پروداکشن خیلی سخت تر میشه track اش کرد که دقیقا منشا اش کجا بوده و بیشتر طول میکشه چون پهنا بیشتری داره.
حالا سوال اینجاست چیکار کنیم موقع review؟ اولین کاری که میکنید اینه که requirement رو نگاه میکنید و تو ذهنتون آنالیز میکنید چه چیزایی نیازه. بعد رو کد میگردین دنبال edge case. ممکنه حتی تو requirement هم به edge case و باگ برسین! تا اینجا فقط باگای لاجیکاله. در درجه بعدی سعی میکنید تستا رو بخونید. اگه pr ای تست نداره, فیچری تست نداره بهتره اصلا مرج نشه. تستا رو که خوندین حتما کیس هایی هست که دستی باید تست شه حداقل یک بار. کیس هایی که شاید خیلی خوب نمیشد تست اتوماتیک نوشت براش. میرین و checkout میکنید و یک دور تست دستی هم انجام میدین. احتمال اینکه باگ پیدا کنید خیلی زیاد میشه اینطوری. و درنهایت میپردازین به مباحث دیزاین کد و پرفومنس اگه جایی مثلا نیاز به decoupling داشت یا جایی نیاز. بود یک queryبهینه تر نوشته شه.
با این فرمول اگه برین جلو اکثر مواقع PR به changes requested میخوره مخصوصا برای نیروی جدید. سعی کنید یک PR رو خیلی گنده نکنید چون review اش خیلی سخت تر میشه و احتمال پیدا کردن باگ کمتر.
یک مشکل دیگه که خیلیا انجام میدن اینه که داخل PR میان بیشتر از تایتلش انجام میدن. مثلا طبق git flow مشخصه یک PR چه چیزایی میتونه باشه. یک pr همزمان نباید هم یک issue رو درست کنه هم یک فیچر اضافه کنه. اگه وسط توسعه به اون issue رسیدین و شناساییش کردین باید یک برنچ جدا بسازین, اون ایشو رو اونجا درست کنید با تست فیل و cherry pick کنیدش رو برنچ فیچری که داشتین کار میکردین که جداگانه review شه و سریعتر مرج شه.
@ManiFoldsPython
👍5🔥1
✅ مقدمه ای بر شی گرایی
مکتب خونه - استاد رامتین خسروی
اگه میخواهید شی گرایی رو با شیب کم یاد بگیرید این ویدئو رو حتما ببینید.
لینک:
https://maktabkhooneh.org/course/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA%D9%87-mk187/%D9%81%DB%8C%D9%84%D9%85-%D8%A2%D9%85%D9%88%D8%B2%D8%B4%DB%8C-ch269/%D9%88%DB%8C%D8%AF%DB%8C%D9%88-%D8%AC%D9%84%D8%B3%D9%87-%D9%87%D9%81%D8%AA%D9%85-%D9%85%D9%82%D8%AF%D9%85%D9%87-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7%DB%8C%DB%8C/
مکتب خونه - استاد رامتین خسروی
اگه میخواهید شی گرایی رو با شیب کم یاد بگیرید این ویدئو رو حتما ببینید.
لینک:
https://maktabkhooneh.org/course/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D9%BE%DB%8C%D8%B4%D8%B1%D9%81%D8%AA%D9%87-mk187/%D9%81%DB%8C%D9%84%D9%85-%D8%A2%D9%85%D9%88%D8%B2%D8%B4%DB%8C-ch269/%D9%88%DB%8C%D8%AF%DB%8C%D9%88-%D8%AC%D9%84%D8%B3%D9%87-%D9%87%D9%81%D8%AA%D9%85-%D9%85%D9%82%D8%AF%D9%85%D9%87-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7%DB%8C%DB%8C/
👍6
Forwarded from سید فرندز / برنامه نویسی / هک و امنیت / تکنولوژی
من تجربه کار کردن با خیلی از دیتابیس هارو به صورت عمیق داشتم
اما گاهی وقتا که میرسم به محاسبات ریاضی حتی موارد ساده گیج میزنم. مخصوصا اگر ۷-۸ ساعت کار کرده باشم و ذهنم خسته باشه
دیشب یک چنین موردی داشتم :
این مدل دیتابیسی بوده. و کوئری که داشتم از قبل این بوده :
میخواستم یک شرط بزارم توی کوئری که اگر در صورتی که مبلغ که قرار بوده پرداخت بشه از مبلغ min_price کمتر بوده باشه اون کارت رو نیاره توی لیست چون پیامک بانک برای اون بانک ارسال نمیشده. مثلا اگر مبلغ ۳۰ هزار بوده باشه و min_price ۵۰ بوده باشه نباید اون کارت بانکی رو نشون بده
این که به این راحتی هستش رو میخواستم تو کد بزنم گیج میشدم. فک کنم تقریبا ده دقیقه نشستم فکر کردم . حتی توی ذهنم استفاده از F فانکشن ها هم اومد.😂
و کوئری درست این بود :
پ.ن :اون order_by که علامت سوال زدم توش به صورت رندم اوردر میکنه و یکیش رو برمیدارم
⭐ @SEYED_BAX
اما گاهی وقتا که میرسم به محاسبات ریاضی حتی موارد ساده گیج میزنم. مخصوصا اگر ۷-۸ ساعت کار کرده باشم و ذهنم خسته باشه
دیشب یک چنین موردی داشتم :
class BankCard(models.Model):
name = models.CharField(max_length=25)
card_name = models.CharField(max_length=50)
card_number = models.CharField(max_length=25)
min_price = models.IntegerField(default=300000)
is_active = models.BooleanField(default=True)
این مدل دیتابیسی بوده. و کوئری که داشتم از قبل این بوده :
BankCard.objects.filter(is_active=True).order_by('?').first()
میخواستم یک شرط بزارم توی کوئری که اگر در صورتی که مبلغ که قرار بوده پرداخت بشه از مبلغ min_price کمتر بوده باشه اون کارت رو نیاره توی لیست چون پیامک بانک برای اون بانک ارسال نمیشده. مثلا اگر مبلغ ۳۰ هزار بوده باشه و min_price ۵۰ بوده باشه نباید اون کارت بانکی رو نشون بده
این که به این راحتی هستش رو میخواستم تو کد بزنم گیج میشدم. فک کنم تقریبا ده دقیقه نشستم فکر کردم . حتی توی ذهنم استفاده از F فانکشن ها هم اومد.😂
و کوئری درست این بود :
BankCard.objects.filter(is_active=True, min_price__lte=price).order_by('?').first()
پ.ن :اون order_by که علامت سوال زدم توش به صورت رندم اوردر میکنه و یکیش رو برمیدارم
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Forwarded from Python BackendHub
backend.pdf
139.7 KB
این مسیر roadmap بک انده. خیلی استاندارد و تمیزه. از سایت roadmap.sh. بهتر از این من ندیدم جایی. یکم کلاد و دوآپس هم بهش اضافه کنید.
اینا رو شما باید بلد باشین. اما بلد بودن چند درجه داره. در درجه اول اینه که اسمشو شنیده باشین. توصیه میکنم حداقل ۳-۴ روز راجب تک تک آیتم های تو این رودمپ یک تحقیق کنید که بدونید چی هستن تا مسیر براتون مشخص باشه.
در درجه دوم شما یک استفاده کوچیک کردین. مثلا تو سلری بروکر رو گذاشتین ریبت. تا اینجا اصلا بلد نیستین درواقع.
تو مرحله سوم شما کمی عمیقتر میشین. ازش استفاده میکنید و چالش هایی تو استفاده ازش بهش برمیخورین. مقاله مختلف میخونید و کارتونو درمیارین. میتونید راجب اون چیز حداقل ۲۰ دقیقه حرف بزنید. بگن ربیت چیه میتونید ۲۰ دقیقه توضیح بدین. تو این level شما یک دانش کاربردی و مختصر دارین. و در نهایت شما کتاب میخونید. عمیق تر میشین. تو پروداکتتون استفاده پیچیده تر میکنید و باهاش بیشتر دست و پنجه نرم میکنید. و تو مرحله اخرم میرین internal اش رو میخونید و حتی contribute میکنید که میشین اکسپرت اون چیز.
@ManiFoldPython
اینا رو شما باید بلد باشین. اما بلد بودن چند درجه داره. در درجه اول اینه که اسمشو شنیده باشین. توصیه میکنم حداقل ۳-۴ روز راجب تک تک آیتم های تو این رودمپ یک تحقیق کنید که بدونید چی هستن تا مسیر براتون مشخص باشه.
در درجه دوم شما یک استفاده کوچیک کردین. مثلا تو سلری بروکر رو گذاشتین ریبت. تا اینجا اصلا بلد نیستین درواقع.
تو مرحله سوم شما کمی عمیقتر میشین. ازش استفاده میکنید و چالش هایی تو استفاده ازش بهش برمیخورین. مقاله مختلف میخونید و کارتونو درمیارین. میتونید راجب اون چیز حداقل ۲۰ دقیقه حرف بزنید. بگن ربیت چیه میتونید ۲۰ دقیقه توضیح بدین. تو این level شما یک دانش کاربردی و مختصر دارین. و در نهایت شما کتاب میخونید. عمیق تر میشین. تو پروداکتتون استفاده پیچیده تر میکنید و باهاش بیشتر دست و پنجه نرم میکنید. و تو مرحله اخرم میرین internal اش رو میخونید و حتی contribute میکنید که میشین اکسپرت اون چیز.
@ManiFoldPython
👍7
جنگولرن
✅ مطلبی از لینکدین Saeed Shahrivari Joghan لینک پست در کامنت سری مهندسی نرم‌افزار: پست1 اولین پست سری مهندسی نرم‌افزار رو با تعریف خود نرم‌افزار شروع میکنم. شاید در نگاه اول تعریف نرم‌افزار برای اغلب افراد کامپیوتری خیلی بدیهی باشه اما بد نیست همین الان…
سری مهندسی نرم‌افزار: پست 2
از لینکدین Saeed Shahrivari Joghan
لینک پست در کامنت
سری مهندسی نرم‌افزار: پست 2
در پست قبلی راجع به نرم‌افزار صحبت کردم و به این رسیدیم که نرم‌افزار شامل کد،داده، و مستندات میشه:
https://lnkd.in/d5Dwkxbt
حالا میخوام یه مقداری راجع به مهندسی نرم‌افزار صحبت کنم. اجازه بدید چند تعریف معروف رو ببینیم:
- «یک نظام مهندسی که شامل هرچیزی درباره تولید نرم‌افزار میشه» از سامرویل
- «پایه گذاری و استفاده از اصول مهندسی برای تولید نرم‌افزار اقتصادی و کارآمد» از بایر
- «استفاده از یک رویکرد سیستماتیک،منظم، و قابل سنجش برای توسعه، عملیات، و نگه‌داشت نرم‌افزار» از IEEE
من اگه بخام نکات مهم در تعاریف بالا رو خلاصه کنم میتونم بگم که:
۱- مهندسی نرم‌افزار یک رویکرد منظم و مهندسی شده باید باشه که شامل فرآیندی کارآمد و قابل سنجش میشه
۲- خروجی مهندسی نرم‌افزار باید یک محصول نرم‌افزاری خوب و باکیفیت و مقرون به صرفه و ... باشه (که فعلا از این ویژگی‌ها می‌گذریم)
۳- به صورت طبیعی باید در این فرآیند مهندسی از ابزارهای مناسبی هم برای توسعه، عملیات، و نگه‌داشت استفاده بشه
حالا با تبیین مفهوم نرم‌افزار و مهندسی نرم‌افزار فقط یه مفهوم دیگه می‌مونه که مفاهیم پایه ما تکمیل بشه و اونم چیزی نیست جز: «مهندس نرم‌افزار»
«مهندس نرم‌افزار کسیه که با استفاده از اصول مهندسی نرم‌افزار و ابزارهای مربوطه محصول نرم‌افزاری میسازه»
الان دیگه محورهای اساسی مباحث رو شناختیم یعنی: «نرم‌افزار»، «مهندسی نرم‌افزار»، و «مهندس نرم‌افزار»
از این به بعد تقریبا اغلب مباحثی رو که در ادامه می‌بینیم به یک یا چند تا از موارد فوق مربوط میشه. برای مثال اگه راجع به آرایش تیمی افراد صحبت کنیم بیشتر به مهندسین مربوطه یا اگه راجع به فرآیند چابک و واکنش به تغییرات صحبت کنیم بیشتر به مهندسی نرم‌افزار مربوط میشه و اگه راجع به کیفیت کد صحبت کنیم بیشتر به خود نرم‌افزار مربوطه. در ادامه من سعی میکنم به مرور تو هر سه محور به موازات پست داشته باشیم ولی فعلا فکر کنم برای رعایت اختصار این پست رو تموم کنیم بهتره.
hashtag#software
hashtag#softwareengineering
از لینکدین Saeed Shahrivari Joghan
لینک پست در کامنت
سری مهندسی نرم‌افزار: پست 2
در پست قبلی راجع به نرم‌افزار صحبت کردم و به این رسیدیم که نرم‌افزار شامل کد،داده، و مستندات میشه:
https://lnkd.in/d5Dwkxbt
حالا میخوام یه مقداری راجع به مهندسی نرم‌افزار صحبت کنم. اجازه بدید چند تعریف معروف رو ببینیم:
- «یک نظام مهندسی که شامل هرچیزی درباره تولید نرم‌افزار میشه» از سامرویل
- «پایه گذاری و استفاده از اصول مهندسی برای تولید نرم‌افزار اقتصادی و کارآمد» از بایر
- «استفاده از یک رویکرد سیستماتیک،منظم، و قابل سنجش برای توسعه، عملیات، و نگه‌داشت نرم‌افزار» از IEEE
من اگه بخام نکات مهم در تعاریف بالا رو خلاصه کنم میتونم بگم که:
۱- مهندسی نرم‌افزار یک رویکرد منظم و مهندسی شده باید باشه که شامل فرآیندی کارآمد و قابل سنجش میشه
۲- خروجی مهندسی نرم‌افزار باید یک محصول نرم‌افزاری خوب و باکیفیت و مقرون به صرفه و ... باشه (که فعلا از این ویژگی‌ها می‌گذریم)
۳- به صورت طبیعی باید در این فرآیند مهندسی از ابزارهای مناسبی هم برای توسعه، عملیات، و نگه‌داشت استفاده بشه
حالا با تبیین مفهوم نرم‌افزار و مهندسی نرم‌افزار فقط یه مفهوم دیگه می‌مونه که مفاهیم پایه ما تکمیل بشه و اونم چیزی نیست جز: «مهندس نرم‌افزار»
«مهندس نرم‌افزار کسیه که با استفاده از اصول مهندسی نرم‌افزار و ابزارهای مربوطه محصول نرم‌افزاری میسازه»
الان دیگه محورهای اساسی مباحث رو شناختیم یعنی: «نرم‌افزار»، «مهندسی نرم‌افزار»، و «مهندس نرم‌افزار»
از این به بعد تقریبا اغلب مباحثی رو که در ادامه می‌بینیم به یک یا چند تا از موارد فوق مربوط میشه. برای مثال اگه راجع به آرایش تیمی افراد صحبت کنیم بیشتر به مهندسین مربوطه یا اگه راجع به فرآیند چابک و واکنش به تغییرات صحبت کنیم بیشتر به مهندسی نرم‌افزار مربوط میشه و اگه راجع به کیفیت کد صحبت کنیم بیشتر به خود نرم‌افزار مربوطه. در ادامه من سعی میکنم به مرور تو هر سه محور به موازات پست داشته باشیم ولی فعلا فکر کنم برای رعایت اختصار این پست رو تموم کنیم بهتره.
hashtag#software
hashtag#softwareengineering
Linkedin
Saeed Shahrivari Joghan on LinkedIn: #software #softwareengineering | 15 comments
سری مهندسی نرم‌افزار: پست ۱
اولین پست سری مهندسی نرم‌افزار رو با تعریف خود نرم‌افزار شروع میکنم. شاید در نگاه اول تعریف نرم‌افزار برای اغلب افراد کامپیوتری… | 15 comments on LinkedIn
اولین پست سری مهندسی نرم‌افزار رو با تعریف خود نرم‌افزار شروع میکنم. شاید در نگاه اول تعریف نرم‌افزار برای اغلب افراد کامپیوتری… | 15 comments on LinkedIn
❤1👍1
جنگولرن
✅ بالاخره بریم برای مطالعه کتاب Fluent Python شاید با این کتاب یکم پایتون یاد بگیریم اگه نکته خاصی وجود داشت. توی کامنت های همین پست قرار میدم.
✅ اولین چیزی که از کتاب Fluent Python یاد گرفتم فانکشن namedtuple بود
در واقع factory function ع namedtuple
✔️این فانکشن ساخته شده تا کار کردن با tuple ها اصولی تر یا بهتر بگم Pythonic بشه. تاپل رو مثل یه class میسازه و قابلیتی میده که با اسم به فیلدهای tuple دسترسی داشته باشیم. در حالت عادی از اندیس ها استفاده می کنیم یا از loop استفاده می کنیم.
توضیحات بیشتر توی لینک های زیر:
https://realpython.com/python-namedtuple/
https://quera.org/blog/collections-in-python/#namedtuple
در واقع factory function ع namedtuple
✔️این فانکشن ساخته شده تا کار کردن با tuple ها اصولی تر یا بهتر بگم Pythonic بشه. تاپل رو مثل یه class میسازه و قابلیتی میده که با اسم به فیلدهای tuple دسترسی داشته باشیم. در حالت عادی از اندیس ها استفاده می کنیم یا از loop استفاده می کنیم.
توضیحات بیشتر توی لینک های زیر:
https://realpython.com/python-namedtuple/
https://quera.org/blog/collections-in-python/#namedtuple
👍4