اهمیت این جدول خیلی بالاس،
بعضی وقت‌ها توی مباحث
Optimization
شرکت که وارد می‌شیم، (البته برای pipeline های پردازشی که سالی ۱ بار آپدیت می‌شوند و ۳۶۵ روز ۲۴ ساعت و ۷ روز هفته در حال پردازش دیتا هستند بدون تغییر حتی ۱ خط کد)

یک همچین جدولی رو از تیم سخت‌افزار تحویل میگیرم؛ توی بحث ما
Access Time
رو کاری نداریم (چون فقط نسبت سرعت مهم هست و همین که ترتیب رو میدونیم کفایت می‌کنه)
اما چیزی که اهمیت پیدا می‌کنه
Size
هست.

اگر بخوام اهمیتش رو ساده توضیح بدم، فرض کنید روی کدهاتون
Scalene
رو اجرا کردید و دیدید که
Cpu idle time
یا همون زمان بیکاری cpu زیاد هست، و فرض کنید شما دارید دیتارو توی ram استفاده می‌کنید.

فرض کنید سناریو realtime هست و این بخش حدوداً ۱۰ مگ دیتا در هر لحظه بهتون میده و این خیلی حجم زیادی هست وقتی روی دیتای متنی کار می‌کنید.

مشکل کجاست ؟ پست بعدی

@PyHints

مشکل اینه که خیلی از دوستان این حجم رو که می‌بینند سریع به load کردنش توی RAM فکر می‌کنند 10MB حجمی نیست، بعد کدهاشون رو تا جایی که توانش رو دارند Optimize می‌کنند و در نهایت هم وقتی نمی‌تونند بهبودش بدهند می‌گن

پایتون سرعت کمی داره

این موضوع قبول ولی بخشی ازین داستان برمیگرده به این موضوع که شما معماری سیستم‌ رو نمی‌شناسید و کاری رو قبول کردید که نیاز به این دانش داره

اهمیت جدول بالا هم دقیقاً همینجا هست، ی موضوعی که همیشه توی کنفرانس‌ها و مراسم معرفی CPU ها اعلام می‌شه سرعت
Compression, DeCompression
هست، که ۹۹٪ بهش دقت نمی‌کنند.

اما این نشون میده اگر من دیتای این مثال ینی ۱۰ مگابایت رو فشرده کنم و از cpu های نسل جدید هم استفاده کنم، می‌تونم دیتای فشرده شده رو وارد
L3 Cache
توی مثال بالا، کنم و بجای سرعت خوندن دیتای
100 ns
از سرعت خوندن داده
30 ns
بهره ببرم که خودش به تنهایی یعنی
1/3
شدن زمان، باقیشم بیخیال ...


قطعاً جدول بالارو توی همه‌ی کتاب‌های درسی و ... دیدید
اما از کاربردش هم اطلاع داشتید ؟
یا دلیل اینکه همیشه سرعت
compression, decompression
اعلام می‌شه رو چطور ؟

@PyHints

این باگ ۱ ماه تیم رو درگیر کرده بود :

توسعه و تست همزمان بصورت پارالل توی تیم‌هایی که هستم پیش میره (اگر تعداد نیرو کافی باشی)

یک بخشی از کد رو داریم که همه‌ی تست هارو به درستی پشت سر میذاره، حتی تست‌هایی که توی pipeline و CI/CD داریم

همه چیز حتی بصورت هفتگی روی سیستم ها درست کار می‌کنه
اما بمحض اینکه میره روی سرور تست‌ خصوصی یا
A/B test

سرعتش تا ۲۰ برابر کندتر می‌شه شایدم بیشتر
ولی این مشکل رو روی سیستم دولوپر‌ها نداریم.

پیدا کردن این مدل باگ‌ها خیلی سخت می‌تونه باشه، ولی خب بالاخره پیداش کردیم.

مشکل چی بود:

if item in mylist:

همین خط کد، ۲ تا مسئله داشتیم،
۱- نیروی junior ایی از طرف شرکت به تیم اضافه شده
۲- توی تیم DevOps هم چون کار روتین شده بوده، سپرده‌اند به یک نیروی Mid-level نگهداری رو

و همزمان ۲ تا خطا انجام شده :
۱- نیروی تیم توسعه و استفاده از in توی پایتون
۲- نیروی تیم DevOps و تبدیل یکی از pipeline های تست، ازش پرسیدند چرا انقدر تست طول می‌کشه بنده خدا رفته چک کرده دیده یک دیتاست بزرگ داریم برای تست
اومده این رو با یک دیتای کوچیکتر جایگزین کرده

و چون نیروی junior توسعه دهنده هم سواد کافی نداشته روی
mylist
توی مثال بالا برای چک کردن اینکه آیا یک نمونه‌ای وجود داره یا نه از
in

استفاده کرده، که روی حجم بالای دیتا منبع اصلی کند بودن هست :

راهکار :
۱- چون روی دیتاهای حجیم کار می‌کنیم، DevOps نباید دیتای تست رو تغییر میداد (اینجوری باگ خیلی زودتر خودش رو نشون میداد)

۲- نیروی تیم توسعه نباید از in و list استفاده میکرد :
۲-۱ : اول به این دلیل که ما اندیس داده رو نمی‌خواهیم فقط وجود یا عدم وجودش توی کدها مهم بوده که نوع داده‌ای set بسیار اینجا کمک کننده بود, همین که بدونیم ۱ مورد وجود داره برامون کفایت می‌کنه این یعنی فضای جستجو کوچکتر

۲-۲ : دستور in بطور کلی کند هست (برای list کوچیک خوبه) باید بجاش از الگوریتم‌ها و ساختمان داده درستش استفاده میکرد که Tree گزینه خوبی هست قطعاً.

دو تا اشتباه همزمان می‌تونه ۱ ماه همه‌ی تیم رو سردرگم کنه

نکته‌ی مهم :
حواستون باشه کجا از in استفاده می‌کنید و مهمتر اگر برای داده حجیم کد میزنید حتماً یکبار روی این حجم داده هم تست انجام بدید.

#خارج‌_از_بحث ولی لازم :

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

که این خودش باعث می‌شه کم کم افول کنند؛ دقیقاً همونطور که مولوی می‌گه :

شکر نعمت نعمتت افزون کند
کفر نعمت از کفت بیرون کند

حالا دلیل منطقی این قضیه چیه ؟
شبکه سازی، من و همه‌ی افرادی که میشناسم خیلی از موفقیت‌هارو مدیون شبکه آدم‌های اطرافمون هستیم، داستان پارتی‌بازی و ... نیستا (دهنمون سرویس شده)

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

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

این بخشش برای تازه‌کارها ☝️☝️☝️

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

شبکه‌ی آدم‌های اطرافمون، خیلی تلاش داشتند که این موضوع رو تماماً گردن شانس بندازند (میدونم از نظر علمی اثبات شده ۵٪ شانس برای موفقیت ۱۰۰٪ لازم هست و شانس منطقی هست)

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

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

خواستم بگم اگر شما هم همچین شرایطی براتون پیش اومد آدمای اطرافتون رو عوض کنید بجای اینکه منکر موفقیت بشید‌، اگر آدمای اطرافتون چشم دیدن موفقیت شمارو ندارند معلوم هست توی این سال‌ها کنار آدمای اشتباهی بودید و حالا که هدف موفق شدن هست

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

و برای اونایی که میگن خوش بحال فلانی که ماهی ۱۰۰-۲۰۰ میلیون یا بیشتر در میاره، کاش منم می‌تونستم و ... باید بگم :

فلانی از خیلی چیزا، تفریحات و ... گذشته تا به اینجا رسیده شما که از مهمونی هم نمی‌گذری بیخود می‌کنی حرف شانس میزنی

برای اون افرادی هم که به موفقیت رسیدن (حتی پله‌های اولیه) :

no one knows the price you paid, so don't care.

@PyHints

#Quick

من این اخطار‌ هارو همیشه زودتر به دوستان نزدیکم میگم
گفتم ازین به بعد بعضی‌هاش رو اینجا هم بگم:

اولین :

asyncio
رو هرچه زودتر یاد بگیرید، پترن‌ها و مفاهیم برنامه‌نویسی
Async, Parallel, Concurent

قبلتر تأکید زیادی روش نداشتم، اما دیر نیست (توی ایران) روزی که حتی
Intermediate python

هم توی مصاحبه باید این مفاهیم رو کامل بدونه.

@PyHints

Guido Van Rossum
رو قطعا دیگه می‌شناسید (خالق پایتون) امروز یک بحثی دیدم مخالف ایشون و تصمیماتی که گرفته و تاثیراتی که گذاشته روی
Cpython
نمیخوام وارد جزئیات بشم ولی بیشتر بحث راجب mojo بود و پستی که گذاشتم راجب تصمیمی که گرفتند و Typing رو تبدیل به ماژول کردند بجای اینکه بیان ی زبان برنامه‌نویسی (اشتباه) یا یک interpreter دیگری برای پایتون ارائه بدند.

mojo

رو نمیدونم خالق‌هاش بهش زبان برنامه‌نویسی گفتند یا طرفدارهاش ولی خب این اولین بار نیست :
Jython, IronPython, IntelPython, ....
این موارد هم هدف‌هایی مثل mojo دارند ولی فقط جامعه خاص یا پروژه خاص سراغش میره.

من این مورد رو توضیح دادم و برگشتیم سر بحث قدیمی پایتون و کوبیدن پایتون ...
GIL (global interpreter lock)

شاید باورش برای تازه‌کار یا تخریب گر سخت باشه ولی همین هم یکی از بهترین تصمیمات
Guido Van Rossum
بوده؛ خیلی از افراد این موضوع رو باور نداشتند و تلاش کردند جایگزین ارائه بدند و نشون بدند که خالق پایتون اشتباه کرده که خب نتیجه مشخص هست تماما همگی شکست خوردند اما این وسط یک پروژه‌ای وجود داره که هدفش donate به جامعه پایتون هست و نه تخریب وضعیت این پروژه هم شکست هست فعلا اما درس‌های زیادی داره اگر دوست داشتید بدونید چرا من از GIL حمایت می‌کنم این لینک رو بخونید :
Project GILectomy state

Larry Hasting
وقتی نهایتا موفق شد GIL رو جایگزین کنه؛ تست های مقایسه‌ای انجام داد و نتیجه‌اش شد این :
"With his complicated buffered-reference-count approach he was able to get his "gilectomized" interpreter to reach performance parity with CPython, except that his interpreter was running on around seven cores to keep up with CPython on one."

به توانایی Cpython رسید ولی روی ۷ هسته پردازشی درحالی که Cpython همون کار رو روی ۱ هسته انجام میداد.
در نهایت اینکه پروژه Gilectomy با ایده‌های جدید همچنان درحال توسعه هست؛ اما همونطور که خالق پایتون گفته بود اگر قرار بود از GIL استفاده نشه و منتظر بمونه شاید هنوز پایتون رو نداشتیم.

@PyHints

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

بلکه اشتباها چیز دیگری تایپ شده

مثلاً صحبت از
Concurrency, Parallelization
بوده و به اشتباه بجای کلمه
Concurrent
از کلمه
Parallel
استفاده شده.

این رو پای دوتا موضوع بذارید :
۱- خستگی
۲- اینکه من وسط نوشتن این متن‌ها، خیلی وقتا برام تسک پیش میاد که اولویت اول روی تسک‌های شغلم هست

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

سپاس از شما🌹 (خود این تشکر هم باگ داشت درست شد)

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

داستان اینه که این پست‌ها نشون میده چطور میشه از اشتباهات دیگران درس گرفت و بجای تجربه کردن شکست از شکست افراد دیگه درس گرفت.
حالا ی وقتایی این پست در حد مشکلات یک پکیج هست یک وقتایی توضیحات کل مشکلات پروژه
مثلاً : discord و مشکلش با mongodb و جابجایی به Cassandra که چندسال قبل ارائه جامعی رو راجبش داشتند و ...
بطور کلی سعی کنید این مدل پست‌ها رو دنبال کنید.


اینجا هم راجب Celery و مشکلاتش صحبت کرده، راه حل بعضی هاش رو هم گفته :

Problems with Celery

#Quick

برای دوستانی که تازه میخوان یاد بگیرند این موضوع رو خیلی مهمه که روی پایتون 3.9 به بعد تمرین کنید و یاد بگیرید این موضوع رو
برای همین کتابی که توی پست pin شده معرفی کردم رو فقط تایید می‌کنم نسخه پایتون اون کتاب 3.10 هست با تغییرات و باگ‌های رفع شده آموزش میده.

برای اوقات فراغت و روزهای تعطیلاتی که داریم، از همین فردا و تا آخر ماه

PyCon 2023 Salt lake city US.

مثلاً یکی از مواردی که خودم به شخصه پاش خواهم نشست یک
Pydantic V2
و اینکه چطور از Rust برای افزایش سرعت استفاده می‌کنه هست، چون FastApi هم ازش پشتیبانی می‌کنه تو ورژن آخر که سرعتش رو خیلی بهتر کرده.


نکته این ویدئوها ضبط شده هست (کنفرانس قبلتر بود و فکر می‌کنم همون موردی هست که خالق
FastApi
و Guido بعدش باهم ملاقات و صحبت داشتند.)

@PyHints

پ.ن : پیشنهاد نمی‌کنم همه‌ی ویدئوها رو همه ببینند، بسته به سطحی که دارید یا موضوعی که کار می‌کنید ویدئو مناسب رو ببینید.

این رو شاید بهتر بود توی کانال هوش مصنوعی بزنم تا اینجا
اما چون پیام‌های زیاد از درخواست برای
Roadmap
متخصص هوش مصنوعی شدن دریافت می‌کنم (توی کانال @pytens پیام‌های پین شده هست) گفتم شاید بهتر باشه اینجا راجبش صحبت کنم :

کار بین‌المللی پیدا کردن در زمینه هوش مصنوعی؛ واقعا سخت شده برای ایرانی‌ها ریموت تقریبا نشدنی شده و حضوری هم سخت هست دلیل اصلی این موضوع هم امنیت داده هست و قوانین سختگیرانه جدید.

اگر واقعا دنبال کار ریموت یا مهاجرت هستید (که بسیار هم کار خوبی می‌کنید) هوش مصنوعی و دیتاساینس رو حتی اگر با تمام وجود بهش علاقه دارید بذارید توی اولویت دوم؛ برای پایتون برید سراغ :
1- Software Engineering
2- Backend Development

علاوه بر اون این ۲ مورد توی کارهای هوش مصنوعی هم خیلی بدردتون خواهد خورد.

شخصا باوجود همکاری های دلاری که داشتم اوضاع رو خیلی خوب نمی‌بینم؛ و درحال حاضر بهترین و راحت‌ترین راهای پیشنهادی و درآمدی دلاری که برام وجود داره آموزش دادن هست (که من اصلا آدمش نیستم؛ دوست ندارم برای آموزش دادن موضوعات پایه از کسی پولی دریافت کنم) و ۹۰٪ پیام‌های درخواست همکاری که توی لینکدین دریافت می‌کنم مربوط به شرکت‌های برگذار کننده دوره‌ی آموزشی هست.

خلاصه که حواستون به هدف‌گذاری باشه و قبل از شروع حتما تحقیق کنید؛ با شرایط فعلی در نظر بگیرید اگر شما ۲ سال دیگه دنبال کار بین‌المللی بخواهید بگردید قوانین دسترسی به داده قطعا سخت‌گیرانه تر هم خواهد شد؛ چون دولت‌ها و قانون گذاران درحال درک اهمیت داده هستند.


پ.ن : هرچی به شهروندی نزدیکتر، شرایط راحت تر

#مزخرفترین_سرویس_دهنده‌‌های_ایرانی

این پیام رو پین می‌کنیم که دوستان حواسشون رو جمع کنند از کی میخوان سرویس بگیرند.

۱- ابرآروان :
down
شدن دائمی ( اکثر مواقع ۱ تا ۶ صبح بوقت تهران)، بخصوص برای ip خارج از ایران

عدم دسترسی به داکر ‌هاب
سرعت کند، برای دانلود از سرورهای خارج از ایران
سرعت کند (کیلوبایت) برای دانلود پکیج‌های
Python, nodejs

هزینه بالا با وجود افت کیفیت

۲- آسیاتک
Down
شدن سرویس؛ در حد ۱-۴ ساعت در ساعات انتهایی شب (داخلی و خارجی)
عدم دسترسی به داکر
سرعت متوسط دانلود از سرویس‌های خارج از ایران
سرعت متوسط دانلود پکیج‌های
Python, Nodejs

۳- ایران سرور
عدم دسترسی به داکر
سرعت متوسط برای دانلود از سرویس‌های خارج از ایران
عدم دسترسی برای دانلود پکیج‌های
Python, Nodejs

درصورت استفاده از ابزارهای مثل شکن و fod و ... دسترسی خواهید داشت اما سرعت دانلود در حدود
۱۰ کیلوبایت بر ثانیه خواهد بود.

هنگام فعال سازی سرویس به خطا هم خورد، که حل مشکل و ایجاد دسترسی حدوداً ۱۰ ساعت وقت برد (کارشناس‌های خودشون حل باید می‌کردند)


شما هم اگر سرویس دهنده مزخرف می‌شناسید لطفاً زیر همین پست اشاره کنید، اگر سرویس دهنده خوبی هم میشناسید کامنت کنید لطفاً 🌹

پ.ن : اگر جایگزینی هم برای
fod proxy, shecan, ...
می‌شناسید، زیر همین پست کامنت کنید.

ایران سرور ۲۰ دقیقه و تا اینجا تونسته
۲۵ مگ از
python dependency
هارو دانلود کنه؛ رکورد شکنی عالی هست.
هیچکس هم تیکت جواب نمیده؛ باز ابرآروان و آسیاتک حداقل میزدن در دست بررسی هست.

بیاید مزخرف‌ترین سرویس دهنده رو فعلا بدیم به ایران سرور

پ.ن : سرعت دانلود
20.6 kB/s

#ایرانـسرور #ایران_سرور

پ.ن : سرویس عودت وجه ایران سرور هم کار نمی‌کنه 😂🤣

به هیچ وجه سراغ این سرویس دهنده نرید.

یک دوستی دیروز راجب لاگ نویسی توی پایتون سوال داشت من به اینصورت براش توضیح دادم گفتم شاید مفید باشه :

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

 3- Handlers

بطور کلی مشخص میکنه با هر پیام لاگی که میاد چیکار باید کرد ؟ اینکه برای info فایل جدا داشته باشیم یا یک سری از اطلاعات رو داخل کنسول / ترمینال نمایش بدیم و … توسط ایشون انجام میشه
بعنوان مثال روی پروژه‌های مهم لاگ‌های سطح critical رو بصورت ایمیل یا پیامک برای چند شخص می‌فرستیم تا سریعتر بررسی بشه و این کار توسط Handler انجام میشه

 4- Filters

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

بنظرم دونستن اهمیت این ۴ تا کامپوننت؛ برای لاگ نویسی از هرچیزی مهمتر هست.

@PyHints

ی سری آدما هم توی لینکدین هستند که برای تبلیغ خودشون، دیده شدن یا تبلیغ کانال و پروفایل :

میان ی موضوع، مطلب در مورد یک آدم بزرگ می‌نویسند
بعد شروع می‌کنند یک تکنولوژی، گروهی از آدم‌ها یا ... رو کوبیدن

در نهایت هم به خودشون رفرنس می‌دهند.

مثلاً طرف در مورد دنیس ریچی می‌نویسه، بعد میگه دنیس ریچی بزرگ هیچوقت در مورد پایتون و جاوا اسکریپت نظر نداد

تازه کل پایتون روی C نوشته شده، یا مثلاً
Engine
مورد نیاز روی node , ... با C نوشته شده و ...
پس تویی که هیچوقت به سورس کد این‌ها اضافه نکردی، چرا این ۲ تا رو مقایسه می‌کنی

ببخشید ببخشید، ولی این حرف اوج حماقت هست بنظرم
برای من زمانی که اول راه بودم همین مقایسه‌ها باعث شد مسیری که بیشتر به روحیات من نزدیک هست رو پیدا کنم

برای من به مراتب پایتون دوست داشتنی تر از C هست (زمانی توسعه دهنده C++ بودم)
برای من به مراتب لینوکس مهمتر و بهتر بوده تا ویندوز و ...

خواستم بگم این مطالب رو لایک نکند، به اشتراک نگذارید یا اگر گذاشتید قبلش کانکشن رو با من قطع کنید.

یادتون نره، قبل از هر پروژه وقتی
System design
رو انجام میدهیم، می‌شینیم و استک ابزارهای مورد نیاز رو باهم بررسی می‌کنیم و تصمیم میگیرم که چه ابزاری رو استفاده کنیم (حالا اینکه بعضی‌ها رو توی این جلسه راه نمی‌دهند داستانش جداس 😉)

پس مقایسه جزوی از زندگی یک برنامه‌نویس هست.

@PyHints

ی زمانی بود پروژه پرداخت یارانه‌ها رو یک شرکت ایرانی میزد

بعد تراکنش و ... رو روی
MongoDB
نگه می‌داشتن، تو مصاحبه یکی از دوستان هم بهش گفته بودن
مگه شما نمیدونی که
mongodb
ورژن ۱۰
mysql
هست ؟

اون دوستانی که dislike کردن فک کنم مشاور این پروژه بودند 🤣

کاملاً واقعی

آقا این جمله قصار :

" مانگو دی‌بی ورژن ۱۰ مای اسکیوئل هست "

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

ی ۱۰ دقیقه اومدیم تلگرام هی باید توضیح بدیم که ببین من توی اون پست نوشتم

گفته بودن، نه اینکه بنویسم گفته بودم

من ۴ سال هست؛ دیتابیس دیزاین روی
MongoDB
انجام میدم. قطعاً انقدر سواد دارم که راجبش نظر میدم 🤦

تورو قرآن درست بخونید 🤦

#موقت

هفته‌ای که گذشت (۷ روز من روز تعطیل ندارم فقط ساعت‌های کاریم کمتر می‌شه)

در مجموع برای جاهایی که کار می‌کنم : ۱۱۰ ساعت کاری پر شده تقریباً روزی ۱۵-۱۶ ساعت

همگی هم دنبال تمام وقت شدن قرارداد من هستند، هیچوقت ناشکری نمی‌کنم چون این انتخاب خودم بودم و دوست داشتم زندگی رو اینطوری تجربه کنم

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

یک نگاهی به مدل کاری خودم و بعضی از دوستانم می‌اندازم، و میگم نکنه ما برداشتمون اشتباه بوده نکنه ما داریم سخت میگیریم ؟

اگر شماهم ازین دسته هستید و با این هدف که زندگی و درآمد خوبی داشته باشید دارید درس می‌خونید، بهتون توصیه می‌کنم ازین دسته بندی فاصله بگیرید :

توی کار واقعی :
من هم مقاله باید بخونم (خیلی خیلی بیشتر و توی موضوعی که شاید علاقه ندارم ولی بیزینس بهم گفته لازم داره)
هم باید پیاده‌سازی انجام بدم
هم خیلی وقتا پیش میاد باید سورس کد یک پروژه دیگه رو تغییر بدم تا خروجی مورد نیاز مارو بهمون بده
هم باید با تیم‌های دیگه تعامل داشته باشم و ....


عادت کنید، درس خواندن سخت نیست (هرچند اگر با این اوضاع ایران و شرایط هزینه‌ای دارید توی ایران درس می‌خونید خیلی کار بزرگی دارید می‌کنید)
ولی می‌خوام بگم کار با دستمزد خوب ازین هم سخت‌تر می‌تونه بشه

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

پ.ن :
این رو برای این هم گفتم که دیگه درخواست حل تمرین یا معرفی کسی برای حل تمرین‌‌هاتون رو برای من نفرستید 🌹

وقتی بالاخره صفحات وب و vscode , ...
پروژه‌هات رو می‌بندی چون همه تسک‌هارو قبل اسپرینت انجام دادی ...
مصرف رم از ۱۰۰ گیگ اومد روی ۲۳ گیگ
باقیش رو تمیز کنیم ببینیم به ۵ گیگ میرسه
کش ۴۹ گیگ آخه 😢

پ.ن : سعی می‌کنم وقتم که آزاد شد پست‌های مهم رو ادامه بدم حتما 🌹

پ.ن ۲ : تا ۳.۵ گیگ اومد

پست روی لینکدین :

LinkdIn URL

این روش رو امروز یادگرفتم و واقعا ای کاش زودتر یاد گرفته بودم چون نیازی نبود ۵-۶ تا ایمیل برای اسپم یا دسته‌بندی کارهام بسازم.