درس هایی راجب برنامه نویسی از زبان Matt Butcher

یادتون باشه هر خط کدی که می‌نویسین باید بعدا ازش پشتیبانی کنین!

این حرف خیلی معنی داره که تو ادامه می‌گم:

- برنامه نویسی به عنوان صنعتگری
- چرخ رو از اول اختراع نکن
- هزینه پیچیدگی
- کاهش نیازهای آینده برای نگهداری
- چرا خود آیندتون (و دیگران) قدردان کد امروزن

برنامه نویسی به عنوان صنعتگری

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

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

چرخ رو از اول اختراع نکن

یه کتابخونه یا ابزاری هست که کار رو راه می‌ندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!
فکر می‌کنم هر مهندس نرم‌افزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:

کتابخونه‌های دیگه‌ای هم بودن، اما سنگین/پر از باگ/پیچیده/و …
یه راه جدید دارم که بقیه بهش فکر نکرده بودن.
انجام دادنش خودم بیشتر یاد می گیرم تا اینکه از کد بقیه استفاده کنم (حرفت درسته، اما با هزینه‌ای خیلی بیشتر از اون چیزی که فکرشو می‌کردی).

تو همه این موارد، دو تا چیز نادیده گرفته میشن:

چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)
منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.

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

هر چی کدت پیچیده‌تر، دیباگش سخت‌تره

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

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

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

خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکرده
پس همه‌چی رو مستند کن! آدما یه جور پیش‌فرض عجیب دارن. فکر می‌کنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون می‌مونه. خود آینده‌ت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.

بهترین راهی که می‌تونی با محدودیت‌های حافظه‌ت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:

کامنت بذار.
اسم‌ها رو خوب انتخاب کن.
مستندات خوب بنویس.
کامیت‌مسیج‌های مفید بنویس.

خود آینده‌ت ازت ممنون می‌شه. یا حداقل از دستت عصبانی نمی‌شه.

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

نتیجه گیری
این قانون رو به عنوان یه راه برای ترغیب کردن خودتون به بهبود کدتون پیشنهاد می‌دم:
یادتون باشه هر خط کدی که می‌نویسین باید بعدا ازش پشتیبانی کنین!
این کار باعث صرفه‌جویی در زمان و انرژی شما در آینده می‌شه. باعث می‌شه همکاراتون عصبانی نشن. تغییر دادن کد امروز به کد فردا رو راحت‌تر می‌کنه. و به احتمال زیاد باعث می‌شه همه فکر کنن شما هم یکی از اون برنامه‌نویس‌های فوق حرفه‌ای هستین.

دیتابیس SQL در مقابل NoSQL: کی چی به کارمون میاد؟

توی دنیای امروز، انتخاب بین SQL و NoSQL می‌تونه گیچ کننده باشه، مخصوصاً با این همه گزینه‌ دردسترس. از دیتابیس های relational مثل MySQL یا PostgreSQL گرفته تا دیتابیس های مدرن مبتنی بر داکیومنت مثل MongoDB یا ذخیره‌سازهای کلید-مقدار مثل DynamoDB، انتخاب بهترین گزینه برای پروژه‌هامون می‌تونه حسابی سخت باشه.

تو این پست قرار این موضوع رو ساده‌تر کنیم و بفهمیم کدومشون برای چه کاری بهتره.

دیتابیس ها SQL چی هستن؟

دیتابیس های SQL که بهشون دیتابیس ها رابطه‌ای (relational databases) هم می‌گن، سال‌هاست که تو دنیای تکنولوژی حرف اول رو می‌زنن. این دیتابیس ها ساختارشون جدولی هست و از یه زبون به اسم SQL (زبان پرس و جوی ساختاریافته) برای تعریف و دستکاری داده‌ها استفاده می‌کنن. SQL برای کارهایی که به انسجام و دقت داده و کوئری های پیچیده نیاز دارن، عالیه.

یکی از مزایای اصلی دیتابیس ها SQL مثل MySQL و PostgreSQL  اینه که با استفاده از relationship ها، می‌تونن از یکپارچگی داده‌ها مطمئن بشن. دیتابیس ها SQL با تعریف یه سری قوانین از قبل، یه جوری داده‌ها رو ذخیره می‌کنن که همیشه دقیق و منظم باشن.


از SQL کجا ها استفاده کنیم؟

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

👈 گزارش‌گیری و تحلیل

👈 انبار داده: از SQL خیلی وقت‌ها برای ذخیره و تحلیل اطلاعاتی مثل اطلاعات مربوط به فروش یا رفتار مشتری‌ها استفاده می‌شه.

دیتابیس ها NoSQL

دیتابیس ها NoSQL مثل MongoDB و ElasticSearch برخلاف پایگاه‌های SQL، رویکردی منعطف‌تر و بدون اسکما (schema-less) برای داده‌ها ارائه می‌دن. این پایگاه‌ها برای مدیریت حجم زیادی از داده‌های بدون ساختار یا نیمه ساختار طراحی شدن و برای مواردی که در اونجا مقیاس‌پذیری، انعطاف‌پذیری و کارایی حرف اول رو می‌زنن، عالی هستن.

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

علاوه بر این، دیتابیس های NoSQL بسیار انعطاف‌پذیر هستن و به توسعه‌دهنده‌ها این امکان رو می‌دن که بدون نیاز به اسکماهای از پیش تعریف‌شده، داده‌های بدون ساختار رو ذخیره و بازیابی کنن. این ویژگی اون‌ها رو برای سناریوهایی که فرمت داده‌ها ممکنه در طول زمان تغییر کنه، ایده‌آل می‌کنه.

از NoSQL کجا ها استفاده کنیم؟

👈 سیستم‌های توزیع‌شده و مقیاس‌پذیر.

👈 داده‌های حجیم و Real-Time Analytics: دیتابیس های NoSQL در سناریوهایی که شامل داده‌های حجیم و تحلیل لحظه‌ای هستن و در اونجا توان عملیاتی بالا و تأخیر کم اهمیت زیادی داره، عالی عمل می‌کنن.اون‌ها به طور معمول در اپلیکیشن‌هایی مانند IoT، تحلیل شبکه‌های اجتماعی و real-time recommendation engines استفاده می‌شن.


تصورات غلط رایج

با وجود تمام نقاط قوتی که دیتابیس های SQL و NoSQL دارن، در موردشون یه سری تصورات غلط رایج وجود داره.

دیتابیس ها SQL انعطاف‌پذیر نیستن: درسته که دیتابیس ها SQL اسکما یا ساختار ثابتی دارن، اما اون‌ها امکانات قدرتمندی برای تعریف روابط بین جداول و اعمال محدودیت‌های یکپارچگی داده ارائه می‌دن.

دیتابیس ها SQL نمی‌تونن به صورت horizontal مقیاس‌پذیر باشن: هر دوی دیتابیس ها SQL و NoSQL می‌تونن به صورت horizontal مقیاس‌پذیر باشن، حتی اگه روش های مقیاس پذیریشون متفاوت باشه

دیتابیس ها NoSQL از transactional پشتیبانی نمی‌کنن: بسیاری از دیتابیس ها NoSQL قابلیت‌های تراکنشی رو ارائه می‌دن، با وجود اینکه با چیزی که تو دیتابیس ها SQL به عنوان ACID شناخته می‌شه، فرق کنه.

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

نتیجه‌گیری

در نتیجه، انتخاب راه‌حل مناسب دیتابیس برای پروژه نیازمند درک دقیق نقاط قوت و ضعف دیتابیس هاس. در حالی که دیتابیس های SQL در یکپارچگی داده قوی و پشتیبانی از کوئری های پیچیده رو ارائه می‌دن، دیتابیس ها NoSQL مقیاس‌پذیری و انعطاف‌پذیری رو به ارمغان میارن و هر دو موارد استفاده خاص خودشون رو دارن و می‌تونن در کنار هم استفاده بشن. در نهایت، انتخاب به ماهیت داده‌های شما و نیازهای خاص اپلیکیشن شما بستگی داره.

بحث داغ زبان‌های برنامه‌نویسی: چرا اصلاً مهم نیست؟


یه بحث همیشگی توی دنیای برنامه‌نویسی هست که توی انجمن‌ها، جلسات تکنولوژی و حتی تو خواب و خیال برنامه‌نویس‌ها هم ول نمی‌کنه: آخرش کدوم زبان برنامه‌نویسی از همه بهتره؟ بشینید پای صحبت های کسایی که از وقتی اینترنت با خط تلفن وصل می‌شد کد می‌نوشتن، تا حالا میگن که کلی زبان برنامه‌نویسی اومده و رفته. از اسکریپت‌های Perl که مثل وردهای جادویی بودن تا TypeScript امروزی که مثل آب خوردن می‌مونه، احتمالا همه جور کدی نوشتن. بعد از شنیدن حرف های ریش سفید های این کار میتونیم بفهمیم: وقتی میخوایم یه مشکلی رو حل کنیم، اصلاً مهم نیست از چه زبانی استفاده می‌کنیم. بله، درست شنیدید!

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

یهویی چی شد؟ یهو همه گیر دادن به پرفورمنس!

طرفدارای یه زبان میگن: "زبان X از زبان Y سریع‌تره!" آره بابا، یه سری تست و بنچمارک نشون میده که یه ذره سرعت اجرا یا مصرف حافظه تو زبونا فرق می‌کنه. ولی بیخیال، واسه 99 درصد برنامه‌ها این فرق‌ها مثه اینه که موقع کدنویسی جوراب قرمز بپوشی یا آبی! مهم معماری، الگوریتم و استراتژی بهینه‌سازیه که کارو راه میندازه. یه سیستم بد طراحی‌شده، چه با Rust نوشته بشه چه با Ruby، آخرش بد و ناکار آمد هستش.

یادگیری زبون برنامه‌نویسی سخته؟

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

لاتاری کتابخونه

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

حرف آخر

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

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

یک مبحثی که خیلی وقت‌ها آدم‌های رو داخل #جنگو گیج میکنه موضوع Aggregation هستش. برای مثال کوئری پایین:

>>> from django.db.models import Avg, Max, Min
>>> Book.objects.aggregate(Avg("price"), Max("price"), Min("price"))
# {'price__avg': 34.35, 'price__max': Decimal('81.20'), 'price__min': Decimal('12.99')}

خب این کوئری مشخصه چه کاری داره انجام میده، همه میتونن بفهمنش مخصوصا وقتی خروجی کوئری رو میبینن، اما اگر ازشون بپرسید خب Aggregation چی هستش هیچ ایده ای ندارن! و این ماجرا از ضعف در دانش SQL سر چشمه میگیره. چون خیلی از آدم‌هایی که دارن #django کار میکنن مستقیم سراغ جنگو اومدن و نرفتن چیزهای دیگه رو مطالعه کنن و یاد بگیرن.

اسم Aggregation داخل ORM جنگو مستقیما از SQL میاد. در SQL یک سری فانکشن وجود داره که بهشون Aggregation functions میگن و کارشون خلاصه سازی اطلاعات:
MIN() - returns the smallest value within the selected column
MAX() - returns the largest value within the selected column
COUNT() - returns the number of rows in a set
SUM() - returns the total sum of a numerical column
AVG() - returns the average value of a numerical column

و خب شما میتونید داخل کوئری‌های SQL ازشون استفاده کنید و دیتا خروجی رو خلاصه سازی کنید و یا یک آمار ازش دربیارید. مثلا میانگین قیمت کتاب‌های تو سال اخیر و ...
یک کوئری مثال برای Aggregation میتونه این باشه:

SELECT AVG(Price) as price_avg FROM Books WHERE puddate=''2023-01-01'';

خب از اونجایی که ORM جنگو در نهایت قرار کار همین SQL نوشتن برای شما انجام بده و کوئری‌ شمارو به SQL تبدیل کنه شما دقیقا همین کوئری میتونید داخل جنگو به این صورت بنویسید:

>>> from django.db.models import Avg
>>> from datetime import datetime
>>> Books.objects.filter(pubdate=datetime(2023, 1, 1)).aggregate(price_avg=Avg("price"))

میتونید لیست فانکشن‌های Aggregation خود SQL داخل این لینک ببینید و ساپورت جنگو هم میتونید داخل این لینک ببینید.

در نهایت از دانش SQL غافل نباشید و حتما یادش بیگیرید. هرچی بیشتر SQL بدونید زندگی راحت‌تری خواهید داشت.

@TorhamDevCH

این روزا بازی همستر طوری سر وصدا ایجاد کرده که اونای که تلگرام نداشتن هم دارن جوین میشن جدیدا تقریبا امروز بالای ۱۵ تا از مخاطب هام وارد تلگرام شدن و هر کدوم یکی در میون لینک دعوت فرستاده 😅😅

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

من فک میکردم درآمد ساقی ها زیاد باشه تا اینکه دیدم ساقی محلمون با همه شماره هاش joined the Telegram

احتمالا همستر وریفای با صرافی بزاره
کاربران آسیا و ایران رو حذف کنه

با سلام و وقت بخیر اگه کسی از دوستان هست که حوزه ماشین لرینگ کار کرده به صورت تخصصی به ایدی بنده که توی توضیحات چنل هست پیام بده ممنون میشم

#Python
یکی پایه های شیء گرایی encapsulation هست، توی پایتون برای اجرا این قانون چند راه مختلف داریم، یکی از اون ها استفاده از دکوریتور ‎[at]property هستش. با بکار گیری این دکوریتور ما برای متغییر های داخل کلاس تعیین میکنیم که چه مقداری بهشون اساین بشه، یا اصلا دسترسی اساین رو میگیریم!!
برای مثال: فرض کنید ما در یک کلاس به متغییری نیاز داریم که فقط عددی از 0 تا 100 داخلش ذخیره کنیم. اسم متغییر رو y در نظرم می گیریم.
در تصویر داخل کلاس یک متغییر به اسم y_ داریم(متغییر هایی که با یک _ شروع بشن protected و اونایی که با ــ شروع میشن private هستن)
متغییر y_ درواقع همون متغییر y هست اما با توجه به اینکه مقدار این متغییر نباید مستقیم توسط instance کلاس تغییر کنه، چون باید حتما بین 0 تا 100 باشه. پس ما یک متغییر protected تعریف میکنیم که مقدار 0 تا 100 رو نگهداری کنه و یک فانکشن به اسم y که به متغییر y_ مقدار بدهد و همچنین مقدار y_ را برگرداند. به این نوع از فانکشن ها property میگن، که getter ,setter و deleter را برای یک متغییر تنظیم میکند(طبق تصویر).

اونوقت بگید LaraGram بده!

امکان ساخت Conversation ها به همین سادگی.

- ولیدیت کردن پاسخ هر سوال
- نام گذاری برای هر سوال جهت پردازش راحت تر.
- ارسال سوال به صورت media
- ساخت Conversation با کیبورد
- مشخص کردن کامند جهت skip سوال
-‏ action جهت اجرا آنی پس از دریافت پاسخ
- مشخص کردن تعداد Attempt
- مشخص کردن Timeout بدون پاسخ ماندن
- مشحص کردن کامند لغو Conversation
- مشخص کردن عملیات پس از Conversation

همه این قابلیت ها تنها با متد های پیش ساخته با یک خط کد

البته که این قابلیت ها در ورژن 2 منتشر میشن😉
https://github.com/laraXgram/LaraGram

👨‍💻📚این روزا چون درگیر امتحان های دانشگاه هستم زیاد وقت نمیکنم که مطلب بزارم ولی خوب یکی از کارهای که در کنار آزمون های دانشگاه دارم انجام میدم این هستش که دارم یه جزوه کامل برای برنامه نویسی پایتون آماده میکنم که دردسترس علاقه مند ها به این زبان برنامه نویسی قرار بدم خیلی سعی کردم تا جایی که میتونم به ذکر جزئیات بپردازم و چیزی رو از قلم نندازم به زودی توی کانال قرار میدم که استفاده کنید👨‍💻📚

✨سرعت تایپ خود را بالا ببرید✨

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

⚡️ در ادامه، تعدادی از راهکار هایی را که در افزایش سرعت تایپ تاثیر گذار هستند، بررسی خواهیم کرد🔥


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

✌️تمرین مداوم:
مانند هر مهارت دیگری، تمرین در تایپ نیز به بهبود سرعت شما کمک می کند. انجام تمرینات تایپی می تواند به صورت تدریجی سرعت و دقت شما را افزایش دهد.



💯شما می توانید با جستجوی عبارت تمرین تایپ یا تایپ ده انگشتی در گوگل به این سایت ها دسترسی پیدا کنید. با تمرین و تکرار ممتد در این سایت ها شما نه تنها به یک برنامه نویس پرسرعت بلکه به یک تایپیست ماهر هم تبدیل خواهید شد.

#Site #programming

شاید نظرم اشتباه باشه ولی، لازمه که بگم :

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

درخواست برای مثلاً، Machine Learning Enginner سوالات مصاحبه :
۱-
۵ سوال اول حاشیه‌ای، من این سوالات رو هیچ وقت جدی نگرفتم و نمی‌گیرم (سوالات مربوط به پایتون و یا مثلاً نحوه آماده سازی و publish پکیج روی pypi)

نظر بنده : این سری سوال مخصوصاً وقتی روی یک کار خاص هست به هیچ وجه نمی‌تونه شمارو ارزیابی کنه (مگر اینکه به شما یک زمان معقول داده بشه و درک شما و نحوه برخورد شما با مسائل جدید رو بخوان بسنجند که بسیار کار درست و خوبیه)
۲-
دومین مورد اینه که از شما راجب الگوریتم و ساختمان داده نحوه عملکرد الگوریتم خاص یا پیاده‌سازی اون.

نظر بنده: اگر قرار باشه شرکت شمارو بعنوان
Software developer, software engineer
یا ... استخدام کنه الزام هست که این الگوریتم هارو بدونید  (منظور از دانستن اینه که بدون گوگل کردن نحوه کار الگوریتم بتونید اون رو پیاده‌سازی کنید ینی تک تک جزئیات رو بدونید.)

۳-
سوال خیلی بهتر و حرفه‌ای تر که شخصاً فقط توی ۱ مصاحبه داخلی دیدم، تعریف یک مسئله خاص هست و اینکه از چه راه حلی برای حل اون استفاده می‌کنی ؟

(معمولاً ساختمان داده و الگوریتم لازمه و نظرم روی قبلی هست ولی خب بهتره)

۴-
دیپ‌لرنینگ چیست؟، ماشین لرنینگ چیست؟ یا ...
نظر من :
جالبی این مدل سوال اینه که ی چیزی توی سایت خوندن و حفظ کردن و هیچ درکی از مفهوم ندارند واسه همین اگر یک مدل دیگه تعریف کنید، هیچی نمی‌فهمند

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

نظر بنده:
این رایج ترین حالت توی ایران هست، همیشه خودتون رو برای مواجه با این افراد آماده کنید، ۸۰٪ موارد شخص روبرتون توی یکی ازین دسته‌هاس (ادمین دیتابیس، وب دولوپر (بکند یا فرانت)، مدیر شبکه، ادمین سرور (ویندوز) ) توی ۱۹٪ موارد هم شانس بیارید ادمین سرور لینوکس یا سیستم دولوپر هست و ی مقدار سوالات بهتر می‌پرسه.
۱٪ تخصص شمارو داره و می‌دونه چی ازتون می‌خواد، ساده‌ترین حالت مصاحبه همینه (چندتا سوال از نحوه پیاده سازی چیزی که می‌خواد می‌پرسه و اونجا باید خودتونو نشون بدید)
---------------

چندتا پیشنهاد برای دوستان مصاحبه گر (هوش مصنوعی یا دیتا ساینس):

۱- سعی کنید سوال جوری باشه که نحوه حل مسئله طرف رو بسنجید، کلی بپرسید و ببینید چه راهکار یا راهکارهایی برای حل اون مسئله ارائه میده ( اینکه بتونه کانولوشن رو از حفظ فرمولش رو بنویسه یا ... یا اینکه اسمهای بزرگ. gpt و ... رو بلد باشه و از حفظ توضیح بده بدرد شما نمی‌خوره ) شخصی مفید هست که بتونه با دیدن مسئله راهکار درست رو ارائه بده این راهکار باید کم هزینه‌ هم باشه و زمان کمی بگیره

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

۳- اگر توی کاری که‌ می‌کنید research هم مهم هست، یک مقاله مرتبط ارسال کنید و یک زمانبندی بدید از شخص بخواید درکش از مقاله رو براتون توضیح بده.

۴- اجازه سرچ کردن به شخص موقع مصاحبه رو بدید و این موضوع رو همون اول بهش بگید، مصاحبه‌های ۱۰-۱۵ سال پیش بود که به توقع داشتیم شخص متقاضی همه‌ی موضوع رو حفظ باشه و ذهنی بگه، الان خود درست سرچ کردن و پیدا کردن راه‌حل یا درک راه‌حلی که توی اینترنت موجود هست از هرچیزی واجب‌تر و مهمتره
همه‌ی ما stack overflow رو روزی چندبار دنبال می‌کنیم، این چیزی نیست که بابتش ناراحت باشیم بلکه بخشی از
کار هست و خوب تخصصیه اگر کسی در کمترین زمان راه‌حل چالشش رو پیدا کنه

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

۶- برای بیزینس MLOPS بسیار اهمیت بیشتری داره تا مدلی با بالاترین دقت، راجب سرعت و نحوه deploy مدل‌ها سوال کنید حتماً
صرف اینکه طرف می‌تونه مدلی رو تولید کنه بدرد شما نمی‌خوره، بیزینس نیازی به تولید مدل نداره
اهمیت روی دیتا و دیپلوی هست

۷- نحوه پردازش و درک افراد از دیتا رو سوال کنید، درک اشتباه ینی راه‌حل اشتباه که ینی خسارت.

-اصل Good Comments در کلین کد

این اصل چنتا زیر مجموعه داره و کامنت های مفیدی که میتونید بزارید رو گفته تو این پست سعی میکنم به طور خلاصه همشون رو بگم

‏1 - Legal Comments
گاها نیازه که تو اول هر فایل سورس یه سری کامنت در باره ارزش های حقوقی پروژه بزارید مثل این کامنت توی FitNesse
// Copyright (C) 2003,2004,2005 by Object Mentor, Inc. All rights reserved.
// Released under the terms of the GNU General Public License version 2 or later.


‏2 - Informative Comments
خوبه که بعضی مواقع یه سریع توضیحات دقیق و مختصر رو کامنت کنیم . البته بهتره تا جایی که میشه اسم تابع این اطلاعات رو بهمون بده ولی اگه نشد یه کامنت بزارید مثلا :
// Returns an instance of the Responder being tested.
protected abstract Responder responderInstance()

‏3 - Explanation of Intent
بعضی مواقع خوبه که قصدی که از نوشتن  اون تیکه کد رو داشتید کامنت کنید (با این که در اکثر مواقع نیازی به کامنت نیست)

‏4 - Clarification
گاها خوبه که اون تیکه از کدمون که یه مقدار مبهمه به صورت ساده شده یه کامنت در بارش بزاریم  مثلا

assertTrue(a.compareTo(a) == 0); // a == a
assertTrue(a.compareTo(b) != 0); // a != b

‏5 - Warning of Consequences
ممکنه یه تیکه کدی داشته باشید که ران کردنش یه عواقبی داشته باشه حالا چه کم چه زیاد
بهتر براش تو کامنتا هشدار بنویسید که برنامه نویس های دیگه حواسشون باشه

‏6 - TODO Comments
بعضی وقتا قصد دارید که بعدا یک قسمتی رو بهبود بدید یا اضافه کنید اینطور مواقع میتونید TODO بزارید که با TODO // شروع میشه معمولا