FDD
خودم شخصا با این روش حال نمیکنم. خیلی تک بعدی میشه و بعدا یقتون رو میگیره. این نظرم شخصیمه البته, ممکنه اشتباه باشه.
@ManiFoldsPython
خودم شخصا با این روش حال نمیکنم. خیلی تک بعدی میشه و بعدا یقتون رو میگیره. این نظرم شخصیمه البته, ممکنه اشتباه باشه.
@ManiFoldsPython
Python BackendHub
حالا برسیم به چالش پروژش که برای من بود و هنوزم هست :)) https://github.com/ultrafunkamsterdam/undetected-chromedriver این لایبری رو میبینید؟ جناب آقای ultrafunkamsterdam که اونرشیپشو دارن, بسیارم تو حوضه خودشون مهارت دارن ولی متاسفانه هرجا دستشون میرسیده…
این باگو یادتونه؟ امروز رفتم سراغش که دیباگش کنم. متوجه شدم که وقتی chrome devtool رو تو undetected روشن میکنید میاد یک listener میذاره رو self.driver. بعد وقتی درایور رو میبندین میاد listener رو که باز کرده میبنده. این لیستنر که خودش بهش میگه reactor از threading.Thread ارث بری میکنه. وقتی self.event.is_set داخل کلس false برگردونه خارج میشه از listener و دیگه درخواست نمیزنه.
اما این وسط یک مشکل داشت 😁
وقتی self.driver استفاده کرده ولی self.driver اومده quit شده و gc هم کالکتش کرده, تازه threading.Thread میره که listener رو ببنده. میبینه self.driver یک رفرنسی هست که به چیزی پوینت کرده که اصلا وجود نداره برای همین کالکتش نمیکنه و ارور میخوره! در نتیجه 2 تا پورتی که گرفته باز میمونه و ESTABLISHED باقی خواهد ماند. 2 تا 2تا جمع میشه تا 65 هزار تا پر میشه. و بعدش port های سیستم پر میشه.
پس وقتی از threading.Thread دارین استفاده میکنید حسابی حواستون به رفرنس هاتون باشه که برای خودتون circular reference درست نکنید. اگه درست کردین حتما باید resolve اش کنید. چطوری؟ صبر کنید تا به ترتیب آبجکت هاتون delete شن بعد ادامه بدین. تو این کیس من برای حل کردنش اول listener رو مطمئن شدم که خارج شده ازش, بعد loop ها رو بستم. بعدش خود آبجکت Thread هم اومدم del کردم. بعدش رفتم سراغ مرورگر و اونو بستم.
پایتون میتونه circular reference رو هندل کنه ولی تو این مورد پورت لیک میموند. دلیلش چیه؟ چون تو ویندوز شما نمیتونید کانکشن هایی که تو یک process ID هستن رو ببندید. ولی تو لینوکس میتونید. بنابراین اگه رو لینوکس از Undetected استفاده میکردین اصلا کانکشن لیک نداشتین.
@ManiFoldsPython
اما این وسط یک مشکل داشت 😁
وقتی self.driver استفاده کرده ولی self.driver اومده quit شده و gc هم کالکتش کرده, تازه threading.Thread میره که listener رو ببنده. میبینه self.driver یک رفرنسی هست که به چیزی پوینت کرده که اصلا وجود نداره برای همین کالکتش نمیکنه و ارور میخوره! در نتیجه 2 تا پورتی که گرفته باز میمونه و ESTABLISHED باقی خواهد ماند. 2 تا 2تا جمع میشه تا 65 هزار تا پر میشه. و بعدش port های سیستم پر میشه.
پس وقتی از threading.Thread دارین استفاده میکنید حسابی حواستون به رفرنس هاتون باشه که برای خودتون circular reference درست نکنید. اگه درست کردین حتما باید resolve اش کنید. چطوری؟ صبر کنید تا به ترتیب آبجکت هاتون delete شن بعد ادامه بدین. تو این کیس من برای حل کردنش اول listener رو مطمئن شدم که خارج شده ازش, بعد loop ها رو بستم. بعدش خود آبجکت Thread هم اومدم del کردم. بعدش رفتم سراغ مرورگر و اونو بستم.
پایتون میتونه circular reference رو هندل کنه ولی تو این مورد پورت لیک میموند. دلیلش چیه؟ چون تو ویندوز شما نمیتونید کانکشن هایی که تو یک process ID هستن رو ببندید. ولی تو لینوکس میتونید. بنابراین اگه رو لینوکس از Undetected استفاده میکردین اصلا کانکشن لیک نداشتین.
@ManiFoldsPython
👍3
برای دیباگ مموری لیک GC هم میتونید از همچین کدی استفاده کنید
@ManiFoldsPython
import gcمود های دیگه هم داره که میتونید از سورس کد ببینید. البته تو این کیس به درد من نمیخورد چون gc فکر میکرد کارشو انجام داده 😅
gc.enable()
gc.set_debug(gc.DEBUG_LEAK)
@ManiFoldsPython
موقع پرزنت کردن اسکیل ها یک مشکلی وجود داره, اینکه یک نفر چون ردیس رو ایمپورت کرده تو پروژه تست جنگوش و یک استفاده basic داشته ازش فکر میکنه درواقع redis بلده در صورتی که واقعا اینطور نیست.
اگه زدین تسلط دارین رو ردیس, پس باید بدونید real time data رو تو ردیس چطور هندل میکنن. باید بدونید race condition چطور هندل میشه. باید بدونید pipe line و watch چیه. باید بدونید lua noscripting چیه و به چه دردی میخوره. باید بدونید چطور بک آپ و snapshot میگیرن ازش. باید بدونید ردیس پاب چطور کار میکنه؟ باید بدونید وقتی رمش پر میشه چه بلایی سرش میاد. باید بدونید LRU policy تو ردیس چیه؟
مثلا لیست اسکیل های یک نفرو میبینی کلی اسکیل زده. خب این شاید اشکالی نداشته باشه, شایدم داشته باشه, ولی حداقل موقع پزرنت اسکیلتون سعی کنید چیزایی که واقعا بلدین و واقعا تخصصتونه رو بگین بلدین, و با بقیه آشنایی دارین. این کلمه تسلط و آشنایی رو خیلیا اشتباه میگیرن. خب تو رزومه معقول نیست جلوی skill بنویسید که این اسکیل رو شما مسلط هستین, یا familiar هستین. اگه چیزایی که familiar هم نیستین رو ننویسید احتمال ریجکت رزومتون خیلی بالا میره. مثلا نوشتن یک docker compose چیزیه که باید همه بلد باشن, ولی انتظار ندارن ازتون که مثلا یک microservice با docker و k8s و doker swarm بالا بیارین که fault-tolerant باشه.
و خیلی سعی کنید کلمه یا تکنولوژی که ازش صحبت میکنید رو حداقل درک کنید که درست باشه. مثلا اینکه sql بلد باشین با اینکه postgresql بلد باشین خیلی فرق داره. وقتی میگین من postgresql آشنایی دارم, یعنی میدونم materialize view چیه. میدونم Full-text search چیه. میدونم date trunc query چیه و به چه دردی میخوره. میدونم postgresql درواقع دیتا تایپ های مختلفی داره مثل json یا Array یا HStore. میدونم تو بحث ایندکس, تفاوتش با sqlite مثلا اینه که partial و functional index داره.
ببینید, نمیگم اینا رو بلد باشین. ولی وقتی میگین با postgresql آشنایی دارین یعنی اینا رو حداقل میدونید. شاید استفاده نکردین یا سراغشون نرفتین, ولی از وجودشون خبر دارین. اگه از وجود اینا خبر ندارین و صرفا یک sql query بلدین اون موقع تو اسکیلتون باید بنویسید sql نه postgresql.
و مهم تر از همه اینا, تو رزومتون اگه به این موارد تسلط دارین, سعی کنید به نحوه تو بولت پوینت هاتون این قضیه رو نشون بدید. تفاوت آشنایی و تسلط تو بولت پوینت باید مشخص شه, نه اینکه جلوی اسکیل ستاره بدین به خودتون.
@ManiFoldsPython
اگه زدین تسلط دارین رو ردیس, پس باید بدونید real time data رو تو ردیس چطور هندل میکنن. باید بدونید race condition چطور هندل میشه. باید بدونید pipe line و watch چیه. باید بدونید lua noscripting چیه و به چه دردی میخوره. باید بدونید چطور بک آپ و snapshot میگیرن ازش. باید بدونید ردیس پاب چطور کار میکنه؟ باید بدونید وقتی رمش پر میشه چه بلایی سرش میاد. باید بدونید LRU policy تو ردیس چیه؟
مثلا لیست اسکیل های یک نفرو میبینی کلی اسکیل زده. خب این شاید اشکالی نداشته باشه, شایدم داشته باشه, ولی حداقل موقع پزرنت اسکیلتون سعی کنید چیزایی که واقعا بلدین و واقعا تخصصتونه رو بگین بلدین, و با بقیه آشنایی دارین. این کلمه تسلط و آشنایی رو خیلیا اشتباه میگیرن. خب تو رزومه معقول نیست جلوی skill بنویسید که این اسکیل رو شما مسلط هستین, یا familiar هستین. اگه چیزایی که familiar هم نیستین رو ننویسید احتمال ریجکت رزومتون خیلی بالا میره. مثلا نوشتن یک docker compose چیزیه که باید همه بلد باشن, ولی انتظار ندارن ازتون که مثلا یک microservice با docker و k8s و doker swarm بالا بیارین که fault-tolerant باشه.
و خیلی سعی کنید کلمه یا تکنولوژی که ازش صحبت میکنید رو حداقل درک کنید که درست باشه. مثلا اینکه sql بلد باشین با اینکه postgresql بلد باشین خیلی فرق داره. وقتی میگین من postgresql آشنایی دارم, یعنی میدونم materialize view چیه. میدونم Full-text search چیه. میدونم date trunc query چیه و به چه دردی میخوره. میدونم postgresql درواقع دیتا تایپ های مختلفی داره مثل json یا Array یا HStore. میدونم تو بحث ایندکس, تفاوتش با sqlite مثلا اینه که partial و functional index داره.
ببینید, نمیگم اینا رو بلد باشین. ولی وقتی میگین با postgresql آشنایی دارین یعنی اینا رو حداقل میدونید. شاید استفاده نکردین یا سراغشون نرفتین, ولی از وجودشون خبر دارین. اگه از وجود اینا خبر ندارین و صرفا یک sql query بلدین اون موقع تو اسکیلتون باید بنویسید sql نه postgresql.
و مهم تر از همه اینا, تو رزومتون اگه به این موارد تسلط دارین, سعی کنید به نحوه تو بولت پوینت هاتون این قضیه رو نشون بدید. تفاوت آشنایی و تسلط تو بولت پوینت باید مشخص شه, نه اینکه جلوی اسکیل ستاره بدین به خودتون.
@ManiFoldsPython
👍12
Python BackendHub
این باگو یادتونه؟ امروز رفتم سراغش که دیباگش کنم. متوجه شدم که وقتی chrome devtool رو تو undetected روشن میکنید میاد یک listener میذاره رو self.driver. بعد وقتی درایور رو میبندین میاد listener رو که باز کرده میبنده. این لیستنر که خودش بهش میگه reactor از …
اینو هرچی بیشتر دیباگ میکنم I’m دارک تر میشه:)) امروز با یکی از دوستان داشتیم دیباگش میکردیم که متوجه شدیم وقتی از asyncio.get_event_loop تو ویندوز استفاده میکنید یک پورت باز میکنه و این اصلا ربطی به undetected نداشت.
حالا اینکه چرا پورت باز میشه نمیدونم ولی این تو windows_event.py هست تو پایتون, و تو ویندوز اتفاق میفته.
نکته جالب اینجاست که gc وقتی آبجکتی رو کالکت میکنه که احساس میکنه نیاز به کالکت شدن داره, و برای port exhaustion تعریف نشده. پس حتی متود
خلاصه اگه از asyncio.get_event_loop رو ویندوز استفاده میکنید حواستون به این نکته باشه که حتما باید close بخوره وگرنه هم مموری لیک خواهید داشت و هم port exhaustion.
سعی کردم PR بزنم به پایتون, اول فکر کردم مشکل از asyncio هست ولی ظاهرا مشکل از gc هست و gc خیلی پیچیده تر و ادونس تر از سطح منه که بخوام PR بزنم و این مشکلو برطرف کنم. بنابراین issue میزنم 😁
@ManiFoldsPython
حالا اینکه چرا پورت باز میشه نمیدونم ولی این تو windows_event.py هست تو پایتون, و تو ویندوز اتفاق میفته.
نکته جالب اینجاست که gc وقتی آبجکتی رو کالکت میکنه که احساس میکنه نیاز به کالکت شدن داره, و برای port exhaustion تعریف نشده. پس حتی متود
__del__ که خودشون نوشتن هیچوقت صدا زده نمیشه, به جز زمانی که اسکریپت متوقف میشه.خلاصه اگه از asyncio.get_event_loop رو ویندوز استفاده میکنید حواستون به این نکته باشه که حتما باید close بخوره وگرنه هم مموری لیک خواهید داشت و هم port exhaustion.
سعی کردم PR بزنم به پایتون, اول فکر کردم مشکل از asyncio هست ولی ظاهرا مشکل از gc هست و gc خیلی پیچیده تر و ادونس تر از سطح منه که بخوام PR بزنم و این مشکلو برطرف کنم. بنابراین issue میزنم 😁
@ManiFoldsPython
👍7
Python BackendHub
اینو هرچی بیشتر دیباگ میکنم I’m دارک تر میشه:)) امروز با یکی از دوستان داشتیم دیباگش میکردیم که متوجه شدیم وقتی از asyncio.get_event_loop تو ویندوز استفاده میکنید یک پورت باز میکنه و این اصلا ربطی به undetected نداشت. حالا اینکه چرا پورت باز میشه نمیدونم…
کد نمونه برای تست:
import asyncio@ManiFoldsPython
import psutil
import os
import gc
def check_connections():
"""Check count of ESTABLISHED connections."""
return len([
conn for conn in psutil.net_connections()
if conn.status == 'ESTABLISHED' and conn.pid == os.getpid()
])
loop = asyncio.get_event_loop()
print(check_connections()) #2
loop = None # or del loop
gc.collect()
print(check_connections()) #2
👍3
Forwarded from DevTwitter | توییت برنامه نویسی
در github که میچرخی ... کدهای ملت اینطوری است که مثلا پایتونها معمولا در چند فایل محدود چند تا کتابخونه معروف صدا و یک کار قابل توجه این وسط با کدهای تجمیع شده انجام میشه ..
کدهای سی شارپ شبیه آفتابه لگن هفت دست شام و نهار هیچی!
صد جور فایل اینترفیس، مدل و انتیتی و ...
و نهایتاً میبینی چند هزار خط کد است که واقعا کار مهمی انجام نمیده و اصل کار هم شاید قابل توجه نباشه...
جاواییها و سی شارپیها زیادی درگیر دیزاین پترن هستند تا کاری که کد باید انجام بده ..
@DevTwitter | <Alireza Shirazi/>
کدهای سی شارپ شبیه آفتابه لگن هفت دست شام و نهار هیچی!
صد جور فایل اینترفیس، مدل و انتیتی و ...
و نهایتاً میبینی چند هزار خط کد است که واقعا کار مهمی انجام نمیده و اصل کار هم شاید قابل توجه نباشه...
جاواییها و سی شارپیها زیادی درگیر دیزاین پترن هستند تا کاری که کد باید انجام بده ..
@DevTwitter | <Alireza Shirazi/>
👎8👍2
DevTwitter | توییت برنامه نویسی
در github که میچرخی ... کدهای ملت اینطوری است که مثلا پایتونها معمولا در چند فایل محدود چند تا کتابخونه معروف صدا و یک کار قابل توجه این وسط با کدهای تجمیع شده انجام میشه .. کدهای سی شارپ شبیه آفتابه لگن هفت دست شام و نهار هیچی! صد جور فایل اینترفیس، مدل…
مزخرف ترین طرز فکر. قطاری کد بنویسید بریزین تو چند فایل. که دیگه بعدا کسی جز خودتون نتونه اونو maintain کنه 🤦♂️
اینجا که به حجم کد اشاره نشده, ولی حتی کد اگه 200 خط هم باشه نباید بدون logic و architecture باشه. چون بالاخره ممکنه درآینده بیشتر برگردین و روش کار کنید. خشت اول رو که کج بذارین ساختمون کج بالا میره, اون موقع وقتی میرسین طبقه 5-10 مجبور میشین ساختمونو خراب کنید و ریفکتور کنید.
لزومی نداره حالا از یک دیزاین پترن خاص و مشخصی استفاده کنید ولی همینکه منطقی باشه و کسی که میبینتش سریع درکش کنه کافیه. هیچ کتابخونه خوبی پیدا نمیکنید که اینطوری نباشه. یک سری قواعد باید همه جا رعایت شه حتی برای کد های کم مثل SOLID و ...
@ManiFoldsPython
اینجا که به حجم کد اشاره نشده, ولی حتی کد اگه 200 خط هم باشه نباید بدون logic و architecture باشه. چون بالاخره ممکنه درآینده بیشتر برگردین و روش کار کنید. خشت اول رو که کج بذارین ساختمون کج بالا میره, اون موقع وقتی میرسین طبقه 5-10 مجبور میشین ساختمونو خراب کنید و ریفکتور کنید.
لزومی نداره حالا از یک دیزاین پترن خاص و مشخصی استفاده کنید ولی همینکه منطقی باشه و کسی که میبینتش سریع درکش کنه کافیه. هیچ کتابخونه خوبی پیدا نمیکنید که اینطوری نباشه. یک سری قواعد باید همه جا رعایت شه حتی برای کد های کم مثل SOLID و ...
@ManiFoldsPython
👍4
مشابه میخواین برین سراغ همین رفیق من undetected chromedriver 😂
یک ریپویی که 5 هزار ستاره خورده
739 تا فورک
ولی کلا 8 تا contributer داره. کسیم سر از کدش در نمیاره. سعی میکنن خیلی به کد دست نزنن چون legacy بزرگی پشتشه 😅
اولین کامیت کد هم 250 خط بود همشو ریخته بود تو یک فایل!
همشم بخاطر همینه که معماری درستی نداشت. شاید یکی بتونه کداشو کلین کنه چون بالاخره خط به خط جلومیری کدو کلین میکنی ولی کلین کردن architecture یک پروژه واقعا پروسه سخت و طاقت فرسایی هست و البته باعث از بین رفتن backward compatibility هم میشه. یک مثال دیگه میزنم از یک پروژه بسیار بزرگ تر تا اینکه این قضیه خشت اولی که کج گذاشته میشه رو جدی تر بگیرین.
@ManiFoldsPython
یک ریپویی که 5 هزار ستاره خورده
739 تا فورک
ولی کلا 8 تا contributer داره. کسیم سر از کدش در نمیاره. سعی میکنن خیلی به کد دست نزنن چون legacy بزرگی پشتشه 😅
اولین کامیت کد هم 250 خط بود همشو ریخته بود تو یک فایل!
همشم بخاطر همینه که معماری درستی نداشت. شاید یکی بتونه کداشو کلین کنه چون بالاخره خط به خط جلومیری کدو کلین میکنی ولی کلین کردن architecture یک پروژه واقعا پروسه سخت و طاقت فرسایی هست و البته باعث از بین رفتن backward compatibility هم میشه. یک مثال دیگه میزنم از یک پروژه بسیار بزرگ تر تا اینکه این قضیه خشت اولی که کج گذاشته میشه رو جدی تر بگیرین.
@ManiFoldsPython
👍2
یک نمونه دیگه از جنگو!
نقل قول از کتاب two scopes of django
اگه query جنگو آبجکت عجیب غریبی نبود و lazy evaluate بودنش خیلی ساده تر پیاده سازی میشد یا اصلا پیاده نمیشد, الان قابلیت تغییر درایور به asyncpg وجود داشت که تو پرفومنس در مقایسه با psycopg شوخیه, و دست زدن بهش باعث از بین رفتن backward compalitity میشه و کلا کل کد و queryهایی که زدین رو باید از اول بنویسید, که خب بنظر نمیرسه حداقل حالا حالا ها همچین اتفاقی بیفته.
@ManiFoldsPython
نقل قول از کتاب two scopes of django
اگه query جنگو آبجکت عجیب غریبی نبود و lazy evaluate بودنش خیلی ساده تر پیاده سازی میشد یا اصلا پیاده نمیشد, الان قابلیت تغییر درایور به asyncpg وجود داشت که تو پرفومنس در مقایسه با psycopg شوخیه, و دست زدن بهش باعث از بین رفتن backward compalitity میشه و کلا کل کد و queryهایی که زدین رو باید از اول بنویسید, که خب بنظر نمیرسه حداقل حالا حالا ها همچین اتفاقی بیفته.
@ManiFoldsPython
👍2
دو فریم ورک برای dependancy injection
Python dependency injection framework, inspired by Guice
Dependency injection framework for Python
@ManiFoldsPython
Python dependency injection framework, inspired by Guice
Dependency injection framework for Python
@ManiFoldsPython
GitHub
GitHub - python-injector/injector: Python dependency injection framework, inspired by Guice
Python dependency injection framework, inspired by Guice - python-injector/injector
👍2
یکی از کارایی که من همیشه میکنم اینه که تو پروژه هام از draw.io استفاده میکنم.
یک markup language هم خودش داره, که باهاش میتونید این جدول هارو بکشید. بعد همون مارک آپش رو آپلود کنید تو سایتش نشون میده جدول رو مطابق عکس
دیزاین پروژه رو داخلش میکشم, حالا میتونه دیتابیس باشه یا design pattern یا هرچیز دیگه ای, بعد همونو تو github repo هم میذارم. اینطوری یک نفر دیگه همون فایلو باز کنه خیلی سریع دیزاین دستش میاد بدون اینکه کد رو بخونه.
@ManiFoldsPython
یک markup language هم خودش داره, که باهاش میتونید این جدول هارو بکشید. بعد همون مارک آپش رو آپلود کنید تو سایتش نشون میده جدول رو مطابق عکس
دیزاین پروژه رو داخلش میکشم, حالا میتونه دیتابیس باشه یا design pattern یا هرچیز دیگه ای, بعد همونو تو github repo هم میذارم. اینطوری یک نفر دیگه همون فایلو باز کنه خیلی سریع دیزاین دستش میاد بدون اینکه کد رو بخونه.
@ManiFoldsPython
👍5🤝2
Forwarded from PGTWEET | توییت برنامه نویسی
من در برنامهنویسی خیلی محافظه کار هستم.
همه چیز رو دوست دارم با خود زبان حل کنم.
و در قدم بعد با کتابخونه استانداردش.
هر پکیج جانبی رو با کلی فاکتور که در ذهنم دارم میسنجم. گاهی روزها طول میکشه تا تصمیم بگیرم به اضافه کردن چیزی!
با فریم ورکهای بزرگ میونهای ندارم...
۱/
اگر نتونم طرز کار یه چیز رو بفهمم، به کدهام اضافه اش نمیکنم.
همیشه فکر میکنم آیا ۵ سال بعد هم میتونم روی این کدها به همین راحتی کار کنم یا نه...
ده بار ساختن یک چیز به صورت کاستوم رو، به ساختن یه چیز جنرال ترجیح میدم...
این مدلی کار کردن محبوب نیست و مخالفان سرسختی داره.
۲/
برای همین خیلی وقتها صحبتهایی که میکنم یا نظرهایی که میدم، از دید سایر افراد خیلی پرت هست.
مثلا یادم هست قدیم ها در اوج محبوبیت django، من با bottle همه کدهام رو میزدم. کتابخونش هزار خط هم نمیشد. یعنی اگر سازندش میرفت زیر اتوبوس، باز من میتونستم کار خودمو راه بندازم باهاش!
۳/
توضیح دادنش برای بقیه سخت بود که چرا من از bottle استفاده میکنم، در حالی که چیزی مثل django وجود داره...
اون دوران که گذشت، ولی امروز هم نمیتونم جور دیگهای کد بزنم.
این روزها ابزارهای رنگ و وارنگ خیلی از قدیم بیشتر شدن...
۴/
ولی من پیش خودم میگم کاری که مثلا فریمورک X داره میکنه رو، من ۷۰٪ اش رو فقط نیاز دارم. از اون ۷۰٪ هم اگر یکم سختی بدم به خودم و اگه همه چیز رو به اون شکل جنرال و عامه پسند نخوام، تقریبا بیشترش رو میتونم خودم بنویسم... مزیتاش اینه که اونطوری با زیر و بماش آشناتر هستم...
۵/
تو چیزایی که نمیدونم و سر رشته ندارم، ترجیح میدم به افرادی که میشناسم و کارهاشون رو مطالعه میکنم اعتماد کنم... ولی در چیزهایی که راسته کار خودمه، خیلی سخت هست به کد شخصی اعتماد کنم که اصلا ندیدمش و هیچی ازش نمیدونم...
۶/
مخصوصا اگر فکر کنم کل کاری که از اون پکیج میخوام، میتونه در حد مثلا ۲-۳ هزار خط بشه، پس چرا این پکیج حجم اش شده ۸۰ مگابایت؟ چرا باید ۸۰ مگابایت کد رو که من هیچی ازش نمیدونم اضافه کنم به پروژهام؟ ریسکاش از نظرم خیلی بالاست... مخصوصا که مثلا خود پروژه ام ۱۰ هزار خط باشه!
۷/
نمیدونم... اینها چیزهایی هست که گاهی با خودم فکر میکنم... اینکه این شکلی کار کردن درست هست یا نه... فقط میدونم که خیلی طرفدار نداره این مدلی کار کردن... خیلی از مواردی که در نفی این روش بهم گفته شده رو شنیدم. ولی بعد از سالها هنوز نتونستم جور دیگهای فکر کنم...
۸.
#تجربه
👤| Amirreza Gh (@amirr3za)
👨💻👩💻|@PGTWEET
همه چیز رو دوست دارم با خود زبان حل کنم.
و در قدم بعد با کتابخونه استانداردش.
هر پکیج جانبی رو با کلی فاکتور که در ذهنم دارم میسنجم. گاهی روزها طول میکشه تا تصمیم بگیرم به اضافه کردن چیزی!
با فریم ورکهای بزرگ میونهای ندارم...
۱/
اگر نتونم طرز کار یه چیز رو بفهمم، به کدهام اضافه اش نمیکنم.
همیشه فکر میکنم آیا ۵ سال بعد هم میتونم روی این کدها به همین راحتی کار کنم یا نه...
ده بار ساختن یک چیز به صورت کاستوم رو، به ساختن یه چیز جنرال ترجیح میدم...
این مدلی کار کردن محبوب نیست و مخالفان سرسختی داره.
۲/
برای همین خیلی وقتها صحبتهایی که میکنم یا نظرهایی که میدم، از دید سایر افراد خیلی پرت هست.
مثلا یادم هست قدیم ها در اوج محبوبیت django، من با bottle همه کدهام رو میزدم. کتابخونش هزار خط هم نمیشد. یعنی اگر سازندش میرفت زیر اتوبوس، باز من میتونستم کار خودمو راه بندازم باهاش!
۳/
توضیح دادنش برای بقیه سخت بود که چرا من از bottle استفاده میکنم، در حالی که چیزی مثل django وجود داره...
اون دوران که گذشت، ولی امروز هم نمیتونم جور دیگهای کد بزنم.
این روزها ابزارهای رنگ و وارنگ خیلی از قدیم بیشتر شدن...
۴/
ولی من پیش خودم میگم کاری که مثلا فریمورک X داره میکنه رو، من ۷۰٪ اش رو فقط نیاز دارم. از اون ۷۰٪ هم اگر یکم سختی بدم به خودم و اگه همه چیز رو به اون شکل جنرال و عامه پسند نخوام، تقریبا بیشترش رو میتونم خودم بنویسم... مزیتاش اینه که اونطوری با زیر و بماش آشناتر هستم...
۵/
تو چیزایی که نمیدونم و سر رشته ندارم، ترجیح میدم به افرادی که میشناسم و کارهاشون رو مطالعه میکنم اعتماد کنم... ولی در چیزهایی که راسته کار خودمه، خیلی سخت هست به کد شخصی اعتماد کنم که اصلا ندیدمش و هیچی ازش نمیدونم...
۶/
مخصوصا اگر فکر کنم کل کاری که از اون پکیج میخوام، میتونه در حد مثلا ۲-۳ هزار خط بشه، پس چرا این پکیج حجم اش شده ۸۰ مگابایت؟ چرا باید ۸۰ مگابایت کد رو که من هیچی ازش نمیدونم اضافه کنم به پروژهام؟ ریسکاش از نظرم خیلی بالاست... مخصوصا که مثلا خود پروژه ام ۱۰ هزار خط باشه!
۷/
نمیدونم... اینها چیزهایی هست که گاهی با خودم فکر میکنم... اینکه این شکلی کار کردن درست هست یا نه... فقط میدونم که خیلی طرفدار نداره این مدلی کار کردن... خیلی از مواردی که در نفی این روش بهم گفته شده رو شنیدم. ولی بعد از سالها هنوز نتونستم جور دیگهای فکر کنم...
۸.
#تجربه
👤| Amirreza Gh (@amirr3za)
👨💻👩💻|@PGTWEET
👍6👎4