Arsham's Tech Mastery
前往频道在 Telegram
درود دوستان، آرشام هستم، مهندس نرم افزار، قصد دارم تو این کانال یه سری مطالب مهم و یادگیری های خودم رو باهاتون به اشتراک بزارم، و به سوالات رایجی که ازم پرسیده میشه پاسخ بدم.
显示更多1 247
订阅者
无数据24 小时
+47 天
+130 天
数据加载中...
标签云
无数据
有任何问题？请刷新页面或联系我们的客服。
进出提及
---
---
---
---
---
---
吸引订阅者
五月 '25
五月 '25
+16
在0个频道中
四月 '25
+9
在0个频道中
Get PRO
三月 '25
+30
在0个频道中
Get PRO
二月 '25
+94
在2个频道中
Get PRO
一月 '25
+60
在0个频道中
Get PRO
十二月 '24
+74
在2个频道中
Get PRO
十一月 '24
+25
在0个频道中
Get PRO
十月 '24
+46
在2个频道中
Get PRO
九月 '24
+37
在0个频道中
Get PRO
八月 '24
+48
在0个频道中
Get PRO
七月 '24
+107
在4个频道中
Get PRO
六月 '24
+21
在0个频道中
Get PRO
五月 '24
+24
在0个频道中
Get PRO
四月 '24
+76
在0个频道中
Get PRO
三月 '24
+56
在1个频道中
Get PRO
二月 '24
+67
在0个频道中
Get PRO
一月 '24
+68
在0个频道中
Get PRO
十二月 '23
+94
在1个频道中
Get PRO
十一月 '23
+101
在0个频道中
Get PRO
十月 '23
+944
在1个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 24 五月 | +1 | |||
| 23 五月 | +1 | |||
| 22 五月 | +2 | |||
| 21 五月 | +1 | |||
| 20 五月 | +1 | |||
| 19 五月 | 0 | |||
| 18 五月 | 0 | |||
| 17 五月 | +1 | |||
| 16 五月 | 0 | |||
| 15 五月 | 0 | |||
| 14 五月 | 0 | |||
| 13 五月 | +1 | |||
| 12 五月 | +1 | |||
| 11 五月 | 0 | |||
| 10 五月 | 0 | |||
| 09 五月 | +1 | |||
| 08 五月 | 0 | |||
| 07 五月 | 0 | |||
| 06 五月 | 0 | |||
| 05 五月 | 0 | |||
| 04 五月 | +1 | |||
| 03 五月 | 0 | |||
| 02 五月 | +1 | |||
| 01 五月 | +4 |
频道帖子
| 2 | تست ستون پروژست!
و همونطور که خونه هایی هم هستن که قدیمی و کاه گلی اند و ستون ندارن، و یه بارون بزنه هم سقفشون میریزه، یا نمیشه به راحتی یا کلا بهشون طبقه اضافه کرد، پروژه هایی هم هستن که تست (ستون) ندارن، و یه فیچر جدید بخوای اضافه کنی تمام فیچر های قبلی میترکه!
زیاد میشنوم که میگن تست به دیباگ کردن کد کمک میکنه، اما این ممکنه یکم گمراه کننده باشه.
این نکته کلیدی فراموش نشه که در خیلی از مدل های تست از جمله unit و integration، ما برای سناریو هایی تست مینویسیم، که سناریو اش رو میدونیم!
در این مدل تست ها، اگه باگی رو با تست دستی نتونیم پیدا کنیم، تست اتومات هیچ کمکی به ما نمیکنه.
پس در واقع با تست اتومات داریم استحکام چیزی که داریم رو تضمین میکنیم.
ولی خب، تو یه سری مدل تست ها مثل e2e و load test هم مجددا سناریو رو میدونیم، با اینحال ممکنه قسمتی از فلو (flow)، مطابق انتظار پیش نره، لود تست که کلا داستان خاص خودشو داره،
ولی تو e2e هم مجددا اگه ایراد پیشبینی نشده ای پیدا بشه، احتمالا در نقاط اتصال هست، و e2e هم تو پیدا کردن باگ لاجیکی غیرمنتظره، کمکی به ما نمیکنه.
<--×-->
دلیل مقاومت بعضی تیم ها و بهونه هایی مثل کمبود وقت برای نوشتن تست، شاید به خاطر ناملموس بودن ارزش افزوده تست ها باشه. با اینحال، تضمین کیفیت و صحت کد های قبلی، موضوع مهم و با ارزشیه، که با نوشتن تست اتومات بدست میاد.
اهمیت این موضوع رو کدبیس های بزرگتر، خیلی بیشتر به چشم میاد.
<--×-->
راجع به دست و پا گیر بودن تست تو فاز های اولیه توسعه، عده ای معتقدن که اگه نیازمندی بیزنس شفاف نباشه، ما هم خود کد و هم تست هاشو باید مدام تغییر بدیم، ولی سوال اصلی اینجاست که چرا نیازمندی بیزنس انقدر باید متغیر (و گنگ) باشه که ورودی و خروجی سیستم بارها، به کل تغییر کنه؟
غیر منطقی به نظر میاد،
اما منم بارها شاهدش بودم!
ولی مسئله اینجا تست نیست،
باید به خیلی قبل ترش نگاه کنیم،
همون جایی که نیازمندی بیزنس داره مشخص میشه.
<--×-->
از خوبی های جانبی تست هم میشه به "مثال بودن" اش اشاره کرد. با فرض دنیای ایده آل، خوندن تست های یه پروژه خیلی ساده تر از خوندن کد خود پروژست، و از رو تست هاش میشه به سادگی فهمید که چیکار میکنه و ورودی و خروجی مورد انتظار سیستم چی هست.
البته خب تو دنیای واقعی و غیر ایده آل، ممکنه یه دولوپر تازه کار مدعی سینیوریتی همین تست هارو فراپیچیده (over complex) کنه.
یه مزیت جانبی دیگه تست هم میتونه بحث تمیزی کد باشه، کدی که تمیز نباشه به راحتی قابل تست نیست، پس در واقع تست مارو مجبور میکنه که کد تمیز تری بنویسیم.
<--×-->
ولی خب در کل نظر شما راجع به تست چیه؟
مزایا؟ معایب؟ پیشنهاد؟ انتقاد؟ به من، به پست، به کانال و... 🙂🙌🏼 | 3 163 |
| 3 | یکی از دوستان دنبال DevOps engineer میگرده برا تیمشون.
اگه فکر میکنید این توضیحات باهاتون الاین هست یا سوالی داشتید لطفا به مهدیار (@MhdyrMrd) پیام بدید.
This is a full-time on-site role for a DevOps Engineer. The DevOps Engineer will be responsible for infrastructure as code (IaC), software development pipelines, continuous integration and system administration. The DevOps Engineer will also be responsible for supporting the AI team by setting up and monitoring data pipelines.
Key Responsibilities
· Design, implement, and maintain automated deployment pipelines for our applications using CI/CD tools such as Jenkins, GitLab CI.
· Collaborate with development teams to streamline the deployment process and improve time-to-market for new features.
· Automate provisioning, configuration, and deployment processes for consistency and scalability.
· Manage and scale clusters for containerized applications.
· Performing monitoring and maintenance activities to ensure system reliability and performance.
· Define and monitoring code quality metrics.
Qualifications
· Solid understanding of Linux systems and architecture
· Experience with Cloud Computing and Containerization technologies such as Docker and Kubernetes
· Experience with Configuration Management tools (Ansible)
· Related certifications are preferred
· Proficiency in Software Development and programming languages such as Python and go are preferred. | 476 |
| 4 | ممبر جدید زیاد داشتیم،
که ممکنه از وجود این دوره آگاه نباشن،
خوشحال میشم این دوره بتونه به خودتون یا دوستاتون کمک کنه.
هر کی استفاده کرده و راضی بوده معرفی کنه به بقیه 🙌🏼
دمتون گرم. ❤️ | 858 |
| 5 | چشامو بستم و باز کردم، دیدم دو ساله که تو اسنپم...
<<--×-->>
بعد از بیرون اومدن از شرکت قبلی،
به تنها چیزی که فکر میکردم مهاجرت بود،
اون موقع با حمایت شما کانکشن های عزیزم شرکتای زیادی بهم پیام دادن، ولی خب چون هدفم مهاجرت بود، همه ایرانی هاش رو ریجکت کردم... به جز اسنپ.
اسنپ که بهم پیام داد، خب بالاخره اسنپ بود! خفن ترین شرکت تکنولوژی ایران رو مگه میشه رد کرد؟ چی از این بهتر که بتونی رو زندگی چند میلیون نفر تاثیر مثبت بزاری...
<<--×-->>
وارد پروسه شدم،
و اتفاقا به خاطر وضعیت اون موقع (اعتراضات) حال روحی اصلا خوبی نداشتم و مصاحبه اولم هم خوب پیش نرفت.
ولی مصاحبه دومم که با نیما قائدشرفی عزیز بود، خیلی خوب پیش رفت و تونستم خودمو نشون بدم، تو همون یه ساعت کلی چیز یاد گرفتم.
سه تا نکتشو یادمه:
اول که خیلی خودمونی شروع کرد و یخ من آدم خجالتی رو شکوند،
بعد راجع به کارا و پروژه های خودم ازم پرسید، نه سوالای تصادفی که ممکنه برحسب اتفاق یه نفر بدونه و یکی ندونه. (وقتی از تجربیات خود شخص میپرسیم، بهش اعتماد به نفس هم میدیم)
و سوم رو توضیحات من راجع به پروژه هام خیلی فلسفی شد، جوری که من مطالعه راجع به "هنر پرسشگری و تفکر نقادانه" رو تو برنامه هام گذاشتم و همینم خیلی تو مسیر شغلیم کمکم کرد.
<<--×-->>
نهایتا موفق شدم و وارد شدم،
خیلی خوشحالم که این اتفاق برام افتاد،
کسایی که از نزدیک یا از پست هام منو میشناسن میدونن که چقدر تو زندگیم تلاش کردم، له شدم، مچاله شدم، اما هیچوقت تسلیم نشدم، تا نهایتا به نقطه ای رسیدم که میگم "آها، این همون نقطه شروعیه که لایقش بودم".
فرهنگ خوبی که تو سازمان جریان داشت منو شگفت زده کرد، کلی نابغه خوش اخلاق تو این سازمان دور هم جمع شدن و منم افتخار حضور کنارشون رو داشتم.
از چیزای خوبی که تو اسنپ دیدم باید پست های زیادی بزارم که بقیه سازمان ها یاد بگیرن، یاد بگیرن که "توجه به نیرو ها، هزینه نیست، سرمایه گذاریه!"، دقیقا کاری که اسنپ میکنه و رشدش رو هم مدیون همینه.
میدونم خیلی تعریف کردم، اما بهم حق بدید بعد دو سال، حالا تشکر و تعریف کنم از سازمان و همکارانم که قلبا همشون رو دوست دارم.
و خوشحالم که اوناهم من رو دوست دارن،
پشت هر میزی میشینم میگن آرشام عضو افتخاری تیم ماست 😂 | 1 084 |
| 6 | یکی از مشکلات اساسی سازمان ها (مخصوصا تو ایران)،
مدام بریده شدن زنجیره انتقال دانش هست!
و متاسفانه توجه زیادی هم به این موضوع نمیشه.
ممکنه بپرسید "حالا مگه انتقال دانش چقدر مهمه؟" یا بگید "وقت برا داکیومنت نداریم" و...
یا بعضا ممکنه فکر کنن که صرفا با شفاهی مطرح کردن دانش، یا چت و...، انتقال دانش به طور کامل انجام میشه، ولی خب موضوع پیچیده تر و مهمتر از اونیه که فکرشو میکنید.
<--×-->
به بیان ساده اش،
انتقال دانش یعنی که یه نیروی قدیمی تر در سازمان، که تجربه خوبی کسب کرده، تجربیاتی که کسب کرده رو به نیرو های بعدی منتقل کنه.
همونطور که قبل تر گفته بودم، هر پروژه ای قرارداد ها و دانش های خاص خودش رو داره.
و البته یه سری دانش عمومی که اونا هم بخش هایی داره که به طور خاص برای هر سازمان مهمتره و اگه توسط نیرو های داخلی منتقل بشه، نیروی جدید کلی جلو میوفته.
حالا چند تا چالش این وسط وجود داره:
- سازمان برای دانش به دست اومده ارزشی قائل نیست، و فقط به محصول بدست اومده از اون دانش اهمیت میده، بنابراین ظرفیت درستی به این موضوع اختصاص داده نمیشه.
- فرهنگ سازمان، انتقال دانش رو به درستی نهادینه نکرده، بنابراین نیرو های ارشد تمایلی به ارتباط در این زمینه ندارن (مگر با تمایل شخصی خودشون)
- تو ایران، چالش مهاجرت، که نیرو ها وقتی که تجربشون به حد خوبی میرسه و زمان میوه دهیشون میرسه، میرن... (حق هم دارن، نیرو ها تو ایران سازمان رو ترک نمیکنن، کل سیستم و کشور رو ترک میکنن)
و...
<--×-->
راه حل؟
- به توانایی نوشتن و انتقال دانش، به چشم یه مهارت ضروری نگاه کنیم، نه یه مهارتی که هعییی، میتونه امتیاز باشه!
این باعث میشه نیرو هامون به سمت یاد گرفتن "انتقال دانش" برن و مشتاق باشن انجامش بدن و نه تنها سازمان بهره ببره، بلکه نیرو تو کل مسیر شغلی اش از داشتن این مهارت لذت ببره! و حتی این کالچر رو به سازمان های بعدی اش هم منتقل کنه.
- به عنوان سازمان، ظرفیت کافی برای انتقال دانش در نظر بگیریم، مثل تیز کردن اره میمونه.
- به عنوان نیرو، همیشه تو ذهنمون باشه که بالاخره یه روزی میرسه که ما تو سازمان فعلیمون نیستیم،
پولی که گرفتیم، فقط برای کاری که کردیم نبوده،
بلکه برای چیزی که یادگرفتیم هم بوده،
از طرف دیگه،
اونی که بعد ما میاد هم یکی مثل خودمونه،
فارق از اینکه حس ما به خود سازمان چی بوده،
باید جوری کار کنیم و میراثی از خودمون بزاریم که اون دوست جدید از همه جا بی خبر، با خودش بگه که نیروی قبلی "اخلاق حرفه ای" داشته.
- برای حل چالش مهاجرت نیرو ها،
سازمان های بزرگ میتونن کمیته های داکیومنت نویسی با ظرفیت اختصاصی برای شفاف سازی و مکتوب کردن دانش ها و فرآیند ها داشته باشن.
نظر شما چیه؟ | 770 |
| 7 | The devil is in the details
شیطان در جزئیات خفته
طی چند سالی که تو رشته کامپیوتر فعالیت میکردم،
مشکلات بزرگ و کوچیک و تغییرات بزرگ و کوچیک زیادی دیدم،
اما به طور جالبی،
بزرگترین مشکلات ریشه در تغییراتی داشت که ورژن پتچ خورده بودن و اونقدر کوچیک بودن که حتی کد ریویو و تست نشدن چون "کوچیک بودن"
ولی بعدش... فاجعه رخ داد.
اما از دید من، هیچ تغییری بی اهمیت نیست،
یه اسپیس اضافه توی فایل یمل میتونه کلا کانفیگ رو خراب کنه و پاد کلا بالا نیاد.
و کاش ته فاجعه بالا نیومدن یه پاد باشه!
یه سری اشتباهات در همین اندازه کوچیک،
موشک ها منفجر کردن و بیزنس ها به خاک نشوندن!
|-×-×-×-|
نیاز به حساسیت رو یه سری موارد در ظاهر کم ارزش اما باطنا تاثیر گذار، باعث شد که با خیال راحت تری برای ریویو کردن کد ها حساسیت به خرج بدم.
الان اینجوری ام که حتی به تک تک اسپیس ها و فرمتینگ های نامناسب کد هم اشاره میکنم.
ولی خودمونیما، چه دلیلی وجود داره که کد فرمت نشه؟
اونم با وجود کلی ابزار برای اتومات شدن این فرآیند؟
چیزی جز مایندست "بزن بره"؟
و چه تضمینی هست کسی که رو فرمت کردن کدش تنبلی کرده، بقیه جاها مثل ساعت کوارتز، دقیق باشه؟
|-×-×-×-|
برای من کد مثل یه اثر هنری میمونه، که هر چی بیشتر به ظرافت هاش توجه بشه زیباتر میشه.
و تو مهندسی، علاوه بر زیبایی، پارامتر هایی مثل کارایی، بهینگی، قابل اتکایی و... هم تاثیر پذیر از توجه به ظرافت ها و جزئیات هستن.
بنابراین به جزئیات دقت کنید،
تمام کامیت های شما میشن اعتبار آینده شغلی شما،
اعتبار شما پیش کسایی که فعلا شمارو نمیشناسن،
اما اسم و کیفیت کارتون رو خواهد شناخت.
دیر رسیدن، بهتر از رو پروداکشن ترکیدن!
|-×-×-×-|
اخیرا دوستی برای مشکلی تو کدش بهم مراجعه کرد،
نمیتونست دیباگش کنه،
به محض اینکه پیچیدگی غیر ضروری و چند لول شرط های تو در تو رو دیدم، گفتم اول این شرط هارو جدا کن یکم کدت رو تمیز تر کن، بعد مشکل خودش خودشو نشون میده.
اول مقاومت کرد و متوجه ارتباط دغدغه من با مشکلش نشد، ولی بعد که براش توضیح دادم چه اتفاقی تو اون قطعه کد داره میوفته متوجه شد که عملا خیلی از جزئیات رو حذف کرده بوده، جزئیاتی که دقیقا خطا در همونا نهفته بود.
و حتی خطاهایی که میتونست خاموش بمونه و تو یه فلوی جانبی خاص، نرم افزار رو بندازه.
|-×-×-×-|
از این موارد و عدم توجه به جزئیاتی که باعث فاجعه شدن زیاد توی تاریخ دنیای نرم افزار وجود داره،
ولی مایندست "بزن بره" هم همچنان به قوت خودش باقیه 🔥😂
واقعیت اینکه گاهی وقتا یه چیزایی برامون شفاف نشده،
و همین باعث میشه ندونیم چه وقت حساس باشیم و چقدر حساس باشیم.
میخوایم جلوی premature optimisation رو بگیریم،
اشتباها کد باگی میفرستیم رو پروداکشن.
چون مرز بهینگی رو مشخص نکردیم،
چون تعریف باگ رو (برا خودمون) مشخص نکردیم،
چون هیچ فریمورکی برای کد ریویو نداریم و کاملا سلیقه ای انجام میشه.
و...
|-×-×-×-|
نظر شما چیه؟ چه مثال ها و نکاتی رو دوست دارید در مورد مطالب گفته شده مطرح کنید؟ | 2 560 |
| 8 | 🔗 با همفکری و همراهی چند تن از دوستان سومین دوره جلسات کتاب خوانی و نقد و بررسی آن را ترتیب دادیم.
جلسات بدلیل فیلتر شدن نرم افزار دیسکورد در ایران، در گوگل میت برگزار میشه. در کامنت های همین پست، جزییات شرکت در جلسات و صوت ضبط شده جلسات را قرار میدیم.
🤝 در این سری جلسات کتاب Designing Data-Intensive Applications (THE BIG IDEAS BEHIND RELIABLE, SCALABLE, AND MAINTAINABLE SYSTEMS) از نشر o'reilly را بررسی خواهیم کرد. آرشام در این پست بیشتر در مورد این کتاب توضیح داده.
🧠 در جلسات قصد هست همانطور که کتاب هم تاکید داره تبیین درستی از کلمه Data در حوزه #توسعه #نرم_افزار برای خودمون ایجاد کنیم. هر چند همین ابتدا تاکید می کنیم، این کلمه Data محدود به حوزه توسعه نرم افزار قطعا نیست.
✨در انتها یک جلمه از هم پیش گفتار کتاب اینجا بیاریم و یادآوری کنیم که یکی از اهداف از سلسه جلسات قبل یعنی بررسی #فلسفه_علم دقیقا فهم چرایی جمله زیر هست که در اونجا با #یادگیری و جداسازی #علم از #ابزار می تونیم با درک عمیق پرسش ها، #تصمیم_سازی های با کیفیت تری داشته باشه.
Software keeps changing, but the fundamental principles remain the same. | 685 |
| 9 |  آقا ساپورت کنید ببینم یک پروداکتهانت رو میگیریم یا نه. 😅
تقریبا ۱۵ ساعت مونده و سومیم. با نفر اول تقریبا ۷۰ تا vote فاصله داریم.
https://www.producthunt.com/posts/hey-7fed5187-9b92-4ee8-9ce5-e08d5bc63d15 | 211 |
| 10 | کتاب آوردم براتون قویییی 🔥✌️🏼😃
کتابی که میخوام معرفی کنم رو خودم حدود ۷۰ درصدشو خوندم، بقیشم دارم میخونم (همزمان البته با چند کتاب دیگه) و سنگین هم هست و بنابراین کند پیش میرم یکم.
ولی مطمئنم خود منو یه پله جا به جا کرد و چند پله دیگه جا به جا میکنه،
و با توجه به ارتباطات نسبتا خوبی که دارم میتونم بگم خوندن این کتاب و درک مطالبش به شما کمک میکنه از درصد قابل توجهی از افراد جلو بیوفتید.
کتاب Designing data-intensive applications نوشته آقای مارتین کلپمن (که ایشون استاد دانشگاه کمبریج هستن و از مهندس های ارشد لینکداین بودن) کتابیه که تمرکزش روی طراحی بهینه نرم افزار هاییه که مسئولیت نگهداری و جا به جایی اطلاعات رو دارن (نرم افزار های statefull، دیتابیس ها، بروکر ها و...)
مخاطب های زیادی میتونه داشته باشه، ولی برای backed engineer ها، data engineer ها، منیجر های تیم های فنی به شدت پیشنهاد میشه. (خودشم مثل اکثر کتابای خوب، تو صفحات اولش کامل توضیح داده برا چه افرادی مناسبه)
کتاب از سه بخش (part) اصلی تشکیل شده:
- foundation of data systems
- distributed data (replication, partitioning, etc.)
- derived data (streaming and batch processing)
بخش اول یه کلیتی از سیستم های اطلاعاتی میگه، و اینکه چه چیزایی تو کار کردن با نرم افزار هایی که با اطلاعات سر و کار دارن مهمه.
خب این یعنی کجا ها؟ همه جا!
شاید یکم اغراق باشه تو "همه جا" که گفتم، اما خود من قبل خوندن کتاب فکر میکردم بیشتر تمرکزش رو یه قسمت محدود از ساختن پایپ لاین های دیتا انجینر ها باشه، ولی بعدش فهمیدم خیلی خیلی گسترده تره.
اینجوری بگم که به عنوان یه مهندس نرم افزار، در روز به روز کارمون با دیتا درگیریم و این کتاب دید خوبی نسبت به دیتا بهمون میده.
بخش دوم میاد میگه اکثر مفاهیمی که راجع به دیتابیس ها (و فراتر البته) گفتیم، برای وقتی بود که روی یه سرور (نود) هستیم، اگه بخوایم همینو رو چندین نود داشته باشیم چه چلنج هایی خواهیم داشت و راه حلشون چیه؟
این بخش سوالات و راه حل های زیادی داره اما تازه شروع کاره، یعنی بعد مطالعه این بخش، کلی سوال دوباره تو ذهنتون ایجاد میشه، اگرچه کتاب به بهترین شکل توضیح داده، ولی خب موضوعش اساسا پیچیده است و به مطالعه و تمرین خیلی زیاد نیاز داره.
این نکته هم بگم که اگر بخش partitioning براتون پیچیده بود و اسکیپ کردید،
همچنان بخش transaction (و پارت سوم تا حد خوبی) میتونه مستقلا خونده بشه و خیلی مفید واقع بشه.
پارت سوم هم راجع به derived data (اطلاعات مشتق شده) هست و فصل هایی مثل batch processing و stream processing رو شامل میشه که به ترتیب بهشون offline و near real-time هم میگن.
این دسته از اطلاعات میشه گفت دیتای دسته اول یا source of truth ما نیستن و ما برای یوزکیس های زیادی که مطرح میشه میسازیمشون (مثلا analytics).
فصل اولش (۱۰ ام کتاب) با یه مثال از فلسفه یونیکس شروع میشه و به طور جذابی با همین مثال کوچیک میره جلو و distribute میکنه و...
پیام خیلی طولانی شد، بررسی ریزتر بخش ها و فصل هارو رو کامنت میکنم.
و پیام هم پین میکنم هر کی هر قسمت این کتاب رو خوند و نکته جالبی دید کامنت کنه.
#کتاب #معرفی_کتاب | 920 |
| 11 | تا حالا شده به یه مشکلی بخورید، ولی هیچ سر نخی از مشکل ندارید، بنابراین اصلا نمیدونید راجع به چی باید سرچ کنید؟ یا هر چی سرچ میکنید به نتیجه نمیرسید. (مثلا یه بار سر مموری لیک تو نود جی اس اینجوری شدم، و نمیدونستم حتی مشکلی که خوردم اسمش مموری لیک هست، مدعیان سینیوریتی هم که... باید براشون میخوندم ای به فدای چشم تو این چه نگاه کردن است!)
یا مثلا یه چیزی رو ندونید، اما ندونید چی باید سرچ کنید که یادش بگیرید؟ مثلا تو مکالمه همکارات بشنوی "p99 اش چنده؟" قبلنا که یادمه گوگل نتایج قابل قبولی برای این نمیداد، ولی ساده است، میگمش بعدا. (کلیت سوالم رو دریابید فارق از مثال)
یه حالت بدتر هم وجود داره، که مشکل خوردن، اما اصلا نمیدونن مشکل خوردن! (مثلا چندتا گوروتین اون گوشه نشستن نون و پنیرشونو میخورن به کسی هم کار ندارن (dangling goroutines))
یا میدونن مشکل خوردن اما بهش بی توجهی میکنن مثلا سرور هفته ای یه بار کرش میکنه، ری استارت میکنن و درست میشه و روز از نو روزی از نو! Availability هم که... کشک! 😂
قسمت سختش وقتیه که میخواید یه سیستم جدید دیزاین کنید،
- نمیدونید از کجا شروع کنید
- نمیدونید چه تصمیمی درست یا غلط، چون پارامتر های مقایسه اش رو نمیدونید
- یا جوانب مختلفش رو بدونید که هست اما نتونید ببینید
اگه این نشونه هارو دارید، راهکارتون پیش دستی تو مطالعه و یادگیریه.
یعنی اگه تا الان با سرچ و تو موقعیت یاد میگرفتید، از این به بعد سعی کنید یه روتینی هم از بدون موقعیت یاد گرفتن داشته باشید.
مثلا خود من الان دارم راجع به کریپتوگرافی میخونم در حالی که تو کارم یا پروژه ای بهش نیاز نداشتم، فعلا صرف علاقه است، ولی وقتی که اسکیلش رو به دست بیارم، میتونم برای موقعیت هایی که این نیازمندی رو دارن شایستگی خودمو نشون بدم.
یا تو همین موقعیتی که هستم نواقصی رو خواهم دید که قبلا نمیدیدم (مطمئنم این اتفاقا میوفته چون چندین بار تجربش کردم)
همه ما برنامه نویسا کم و بیش این دوره رو تجربه کردیم که نه بر حسب نیاز بلکه برای آینده مطالعه کنیم (قبل اولین کارمون مثلا)، اما گاهی بعد اینکه دیگه به کار میرسیم انقدر غرق کار میشیم که یادمون میره این مسیر طولانی تر از این حرفاست و کلی موقعیت برا پیشرفت هست. (بعضیا هم میدونن موقعیت هست ولی تصمیمشون بر لذت بردن و... در تایم های شخصیه، اونم مورد احترامه) | 9 333 |
| 12 | داستان یه پروژه شخصی (پادکرایب)
من پروژه های شخصی زیادی دارم،
بعضیاشو دارم همچنان پیش میرم،
بعضیاشو رها کردم،
بعضیاشم هنوز شروع نکردم،
خلاصه مثل خیلی دیگه از برنامه نویسا 😅😂
ولی داستان پروژه پادکرایب برام داستان جالبی بود،
داستان از اینجا شروع شد که من پادکست زیاد گوش میدادم،
ولی خب فهمیدن پادکست یکم سخت تر از دوره و آموزش و... است، خیلی خودمونی حرف میزنن و شمرده حرف زدن در حد آموزش، الزاما جز اهدافش نیست.
خواستم متن پادکست هارو پیدا کنم، چیزی پیدا نشد،
یه سری ابزار هم برای ویس به متن بودن که همه پولی و پرداخت دلاری،
تا اینکه با پروژه ویسپر آشنا شدم،
اول از همه فلو رو دستی اجرا کردم،
ویسپر mp3 ساپورت نمیکرد و باید wav بهش میدادم،
پس فلو میشه این:
- کراول پادکست
- دانلودش به صورت کانکارنت
- تبدیلش به کمک ffmpeg
- بیلد و ست آپ ویسپر لوکال
- تبدیل ویس به متن
حالا نوبت چسبوندن این قطعات به هم بود،
- یه فایل باینری ffmpeg که کار تبدیل (mp3->wav) رو انجام میده،
- پروژه ویسپر که به زبان C نوشته شده و ست آپ خاص داره،
- یه سری کد گولنگی برای مدیریت برنامه و مدیریت دانلود
دوست عزیزم محمد جهانی اینجا کمکم کرد بهم گفت که اینجور پروژه ها معمولا یه چیزی دارن به اسم bindings (کلمه جدیدی بود برام)
و بایندینگ های ویسپر و ffmpeg رو پیدا کردیم (اتفاقا رو بایندینگ ffmpeg بعدا که کانتریبیوت هم زدم)
همون موقع ها بود که دوستم مبینا هم بهم پیام داد که میخواد رو یه پروژه اپن سورس کار کنه (پادکرایب رو اولش قرار بود به صورت یه ابزار cli و یه بات تلگرامی رایگان و اپن سورس ارائه بدم) و خیلی کمکم کرد (فیچر دانلودر و کراول کست باکس رو زد، یه سری ایده سر تسک ها داد و...)،
منتها بایندینگ های ویسپر خیلی مشکل داشت،
به این شکل که باید خود ویسپر رو کلون میکردیم،
و go get اش هم باید میکردیم،
و اینا version mismatch میخوردن گاهی الکی،
و باید یه ریپلیس هم تو گو مود میزدیم.
و از یه جایی به بعد هم، ایمیج ما رو پایپ لاین بیلد میشد اما دیگه روی لپتاپ من بیلد نمیشد (به خاطر ناسازگاری Apple M1)
یه ایشو باز کردم رو ویسپر و آقای josharian از خفنای اپن سورس گولنگ، با نیم خط کامنت فیکسش کرد 😁
هیچی خوب پیش نمیرفت تا اینکه گوگل اومد اعلامیه داد گوگل پادکست رو میخواد با گوگل موزیک مرج کنه 😂
ما کست باکس هم داشتیم،
کراول اپل پادکست رو البته گذاشته بودیم برا بعدا،
ولی خب بعد این خبر رفتیم رو هوا 😂
باز من کراول زیاد انجام دادم و اگرچه که گوگل شدیدا مقاوم و سخت گیره ولی شاید میشد یه سری تریک زد حلش کرد،
مسئله مشکل دیگه ای بود که داشتیم،
پروسه تبدیل ویسپر خیلی سنگین و زمان بر بود،
اینجوری بگم که نمیصرفه هر جایی ران اش کنی،
اما من تسلیم میشم؟
نه پیوت میکنم 😂
عوض کردم همه چیزو،
- کامند لاین کنسل (فعلا فقط بات تلگرام)
- استفاده از OpenAI API به جای ران کردن مدل توسط خودم
- اولویت دادن ترنسکرایب هر نوع صدا، نسبت به صرفا پادکست
- و برای هزینه خدمات بالا، باید فیچر های پرداخت هم بزارم.
خب الان چه کنیم؟
بکوبیم از نو بسازیم پروژه رو،
یه قسمتایی از پرداخت کریپتویی رو زدم،
و با OpenAI API هم ارتباط گرفتم،
چندتا کانتریبیوت هم این وسط زدم،
بعد تلگرام stars اومد 😂
وسطای پروژه هم یه جایی تلگرام پرمیوم فیچر تبدیل ویس به متن تبدیل ارائه داد.
و بعدشم متوجه شدم اپل پادکست خودش متن همه پادکست هارو داره.
بابام همیشه میگه، هر کسی سهم خودشو از بازار میبره،
ولی خب، اینجا دیگه سهم پروژه من خیلی کوچیک شد،
فکر کنم دیگه وقتشه پروژه رو شکست خورده اعلام کنم و بیخیالش شم، با اینکه البته درسای خیلی زیادی برام داشت.
میتونم اینجوری بگم، انقدر که من از پروژه های شخصیم یاد گرفتم و لذت هم بردم، تو هیچ کدوم از شرکت هایی که بودم یاد نگرفتم و لذت نبردم.
یه سری از درسایی که گرفتم رو تو کامنت ها میگم،
شما هم اگه نظر و تجربه مشابهی دارید خوشحال میشم بشنوم. | 930 |
| 13 | درود عزیزان وقت بخیر،
یکی از دوستان برای ویرایش مقاله های GenAI دنبال یه دولوپر میگرده که بتونه کار ویرایش متن فارسی رو انجام بده، دولوپر لازم داره چون باید متوجه کانسپت بشه و جملهبندی و اصطلاحات فارسی درست رو انتخاب کنه.
برای هر مقاله هم ۲۰۰ تومن میده،
اینکه دیگه چقدر سخته یا میصرفه و... رو من نمیدونم و فقط دارم اطلاع رسانی میکنم،
بهم پیام بدید وصلتون کنم به خودش.
https://github.com/Gilas-io/website/blob/master/contribution/README.md
https://cookbook.openai.com/examples/summarizing_long_documents | 391 |
| 14 | یکی از ابزار های معروفی که چند سالیه خیلی سر و صدا کرده و چند باری اسمش رو آوردم تو کانال، کوبرنتیزه (#Kubernetes)،
این ابزار برای مدیریت کانتینر ها استفاده میشه، که البته تو اسکیل بزرگ، کار بسیار سختیه (مثال بگم استارت آپ های تاپ ایران، تو رنج های چند صدتایی پاد دارن، پاد رو "فعلا" معادل یه سرویس از مایکروسرویس بگیرید، هر چند که تعریف دقیقی نیست، همچنین میتونه یک یا چند کانتینر و یه سری تنظیمات تو دل خودش جا بده).
نتورک بین پاد ها و خارج کلاستر، مدیریت کانفیگ ها، تقسیم کانتینر ها توی سرور های مختلف (#distribution)، ترمیم خودکار (auto-healing)، مدیریت منابع، اسکیل آپ و داون، و خیلی کارای دیگه... رو برای ما آسون میکنه.
قصد ندارم ریزشو تو این پست بگم، صرفا میخواستم یه کتاب معرفی کنم براش 😄
کتاب Kubernetes Up & Running رو پارسال یکی از دوستام تو اسنپ بهم معرفی کرد و با هم خوندیمش.
من قبل خوندنش کار کردن با کوبر رو تا حدی تجربی بلد بودم، پنج شیش فصل اولش رو فقط ورق زدم ولی بازم چندتا نکته خوب داشت، بقیش جدیدتر بود و زمان بیشتری گذاشتم.
البته این کتاب راجع به اینترنال کوبر یا چلنج های کوبر توی اسکیل بزرگ نیست، ولی به عنوان
A beginners guide to Kubernetes
A touch on the surface of Kubernetes
و... میتونم بگم عالیه، مختصر اما مفید توضیح داده.
تقریبا فصل هاش بر اساس ریسورس ها هستن (ریسورس ها تو کوبر یه سری موجودیت ها هستن که کاربرد های مختلفی دارن، خود پاد یه ریسورسه) و ترتیب خوندن فصل ها اوایلش مهمه (فصل پاد مثلا، که همه جا اسمش هست)، اما فصل های بعدش رو تقریبا میشه مستقل هم خوند.
و از اون کتاباییه که بهتره لپتاپ هم کنارتون باشه و کوبرنتیز رو ست آپ کرده باشید، چون مثال زیاد داره. (با داکر دسکتاپ یا microK8s یا K3s به راحتی میتونید یه کوبر لوکال بالا بیارید)
برا من یه چند جاییش سر بحث های نتورک یکم گنگ بود، چون کتاب مختصریه نمیتونه به اون موضوع هم دیپ بپردازه، منم راستش دانش نتورکم کمه که بی دلیل نبود، در کل از فیلمای یوتیوب و مقالات مدیوم خیلی عمیق تره، ولی بازم یه جاهایی فقط کلید واژه میده و خودتون باید برید عمیق تر بخونید.
نکته مهم 🔥: من میخوام یه پروژه کوبری اپن سورس استارت بزنم، که کار من تنها نیست، اگه تازه کار هستید خوندن این کتاب میتونه زمینه خوبی بهتون بده که بتونیم پروژه رو قوی تر روش کار کنیم. (البته که دانش فارق از هر راهی که بدست بیاد ارزشمنده، چه کتاب، چه آزمون و خطا و...)
#معرفی_کتاب #کتاب | 806 |
| 15 | کتاب Concurrency in Go رو خیلی وقت پیش خوندم ولی الانم نیازمند دوباره خوندنه،
کتاب کوچیکیه اما نصفش زیر زمینه 😂
خیلی خوب نوشته شده، اما موضوعی که راجع بهش صحبت میکنه در نهایت پیچیدست، حتی وقتی تو کتاب هم متوجه اش میشید، پیاده سازی هاش توی پروژه واقعی پیچیده تر از نمونه های ساده سازی شده کتابه و نیازمند تمرین و تجربه است.
بهتره قبل از خوندن کتاب، در حد مقدمات کانکارنسی رو بدونید و تمرین کرده باشید، آموزش های من برای قبلش کافیه:
https://t.me/ArshamTM/18
برای بعدش، کلی تمرین و تمرین...
در نهایت اگه میخواید کانکارنسی توی گولنگ (و گاها یکم فراتر از گولنگ) رو به خوبی یاد بگیرید این کتاب میتونه خیلی کمکتون کنه.
#معرفی_کتاب #کتاب #concurrency #go | 819 |
| 16 | به تازگی کتاب
A Common sense guide to Data Structures and Algorithms
رو از یکی از دوستای خوبم هدیه گرفتم و خوندم.
کتاب خیلی خوبیه، خیلی روان و با شکل و مثال، دیتااستراکچر هایی مثل
Arrays, Hash maps, Stack, Queue, Linked list, Tree, BST, Heap, Graph, etc.
و الگوریتم های مختلف و معروف جستجو،
و نحوه بدست آوردن و مقایسه پیچیدگی زمانی و پیچیدگی حافظه رو توضیح داده، و تکنیک هایی برای بهینه کردن الگوریتم ها گفته.
همچنین چند فصلش هم به recursion اختصاص داده و به خوبی توضیحشون داده.
این کتاب میتونه شروع خوبی برای دیتااستراکچر و الگوریتم باشه، و پیشنهاد میدم اگه مواردی که بالا گفتم براتون جدید یا گنگه، حتما این کتاب رو بخونید،
برای خود من که قبلا مطالعاتی داشتم اکثرش تکراری بود ولی بازم چند تا نکته خوب داشت و از شیوه نگارش نویسنده هم لذت برم.
زبان انگلیسی کتابش هم زیاد پیچیده نیست، پس اگه زبانتون زیاد خوب نیست هم به نظرم زیاد نگران این موضوع نباشید.
عکس کتاب در کامنت، خودم چاپی خوندم پی دی اف اش رو ندارم.
#معرفی_کتاب #کتاب #datastructure_and_algorithms | 838 |
| 17 | آدام گرنت (adam grant) رو احتمالا خیلی هاتون به خاطر کتاب معروفش به اسم "دوباره فکر کن" (think again) بشناسید،
توی این ویدئو فوق العاده، راجع به آدمایی که دانششون رو به اشتراک میزارن (givers) در مقابل آدمایی که فقط دنبال منفعت خودشونن (takers) صحبت میکنه.
ویدئو فوق العاده ایه و چقدر قشنگ حرف دلمو زد
https://www.youtube.com/watch?v=YyXRYgjQXX0
شخصا تجربه های تلخ زیادی از selfless giver بودن داشتم*، ولی پشیمون نیستم و دوست دارم بازم تا جایی که میتونم به بقیه کمک کنم، در جواب هم توقعی جز احترام متقابل از هیچکس نداشتم.
من اعتقادی هم به چیزای متافیزیکی مثل قانون جذب و... ندارم، و معتقدم تاثیر کمک ما خیلی طبیعی تر از این حرفا به دستمون میرسه،
من اگه به دو نفر کمک کنم و اونام به دو نفر و...
در نهایت یه تاثیر نمایی رو کل جامعه (که جامعه میتونه یه دانشگاه، یه شرکت، یه کشور یا... باشه) میزاره، جامعه ای که من هم دارم توش زندگی میکنم، و بار ها این تاثیر مثبت و لذت بخش رو به چشم دیدم.
<<------>>
راجع به takers، چند ماه پیش یه پست تقریبا مرتبط براتون نوشته بودم با تایتل "مایندست جویندگان طلا!"
که متاسفانه کلی نوشتم ولی نتونستم ببندمش 😂
خلاصه اش این بود که علم مثل طلا نیست که فقط یه مقدار محدودی ازش باشه و سر مالکیتش دعوا کنیم،
علم یه ویژگی شگفت انگیز داره و اون کپی شدنه!
و جالب تر اینکه هر چقدر بیشتر کپی بشه اتفاقا ارزشمند تر هم میشه! شاید بشه یه سری علوم انحصاری خاص رو تو این تعریف نیوورد، نمیدونم، ولی مطمئنم درصد خیلی بالایی از خساست های علمی بی مورده و صرفا از روی حس های منفی دیگست (مثل حسد یا ترس) که دیگه میره تو چارچوب روانشناسی و کار من نیست 😄
<<------>>
پ.ن: برای عزیزانی که میگن ما کمک کردیم ولی بدی دیدیم و پشیمونیم، حق میدم، منم چشیدم تلخیشو، آدام گرنت هم اتفاقا اشاره کرده بود به این موضوع، ولی خوبی خودتون رو فدای بدی یه عده معدود نکنید!
<<------>>
در نهایت، من فقط حواسم رو جمع میکنم آدمایی که هدفشون "آزار مردمه" برای رسیدن به این هدف ازم سواستفاده نکنن و به نظرم همین قدر کافیه و تو بقیه موارد میتونم خودم باشم، هزار نفرم که بهم خیانت کنن میدونم که مسیر مهربونی قشنگ تره و قوی و محکم این مسیر رو ادامه میدم. ✌️🏼🔥 | 779 |
| 18 | به به! خیلی وقت بود منتظر این مستند بودم (هانی پات کلا مستند های خوبی میسازه و یکی دو ماه پیش اطلاع داده بود میخواد اینو بسازه)
تازه از تنور در اومده 🔥
راجع به نود جی اس هست:
https://www.youtube.com/watch?v=LB8KwiiUGy0
------
همچنین حالا که صحبتش شد پیشنهاد میکنم مستند revolution os هم حتما ببینید، فوق العاده جذابه، راجع به لینوکس + اپن سورس هست و ریچارد استالمن عزیز و بقیه دوستان توش صحبت میکنن.
------
مستند و فیلم خوب (در این حوزه) داشتید معرفی کنید تو کامنت. 🙌🏼 | 992 |
| 19 |  قراره توی عید یک بازی تلگرامی مشابه Quiz of Kings رو با هم توی چند تا یوتیوب از صفر تا صد پیادهسازی کنیم.
اولین لایو فردا جمعه ساعت ۱۲ شروع میشه و اگه میخواید لایو های بعدی رو از دست ندید توی کانال @MhrCode یا گروه @MhrCodeGp عضو بشید تا قبل از هر لایو تایم دقیقش رو بذارم.
بعد از اتمام لایوها به فرمت قبلی ویدیوها ادیت شده و به شکل خلاصه توی کانال یوتیوب قرار میگیره.
لایوها توی کانال یوتیوب https://youtube.com/@mhr_code خواهند بود
استکی که قراره باهاش بازی رو بسازیم: Golang, HTMX, Alpinejs | 685 |
| 20 | منابع رایج یادگیریمون:
یوتیوب، استک آورفلو، مدیوم و بلاگ های مشابه، یودمی و بقیه کورس ها، داکیومنت های رسمی.
همچین:
کتاب و پادکست
<<----->>
ولی یه سری منبع هم هستن که فوق العاده اند اما شاید از چشمتون مخفی مونده باشن از جمله:
- تِک بلاگ (Tech Blog) های پروژه های بزرگ، مثلا بلاگ گیتهاب و داکر خیلی فعالن، یا بخش case studies ها توی سایت رسمی گولنگ، هزاران تا تک بلاگ هست که پروژه های واقعی داستان های شگفت انگیزشون رو تعریف کردن.
اینجا هم یه لیست خوب ازشون گذاشتن:
https://github.com/kilimchoi/engineering-blogs
- کنفرانس ها (یوتیوب)، چیزایی که معمولا تو کنفرانس ها دیدم بسیار ارزشمند بوده، چیزایی که شاید تو توتوریال های فانتزی و قشنگ مشنگ پیدا نکنید! اگرچه که شاید گاهی وقتا شخص ارائه دهنده پیچیده تر صحبت کنه.
دقیقا پیونتش همینه،
یه وقتایی افرادی تو کنفرانش ها صحبت میکنن، که وقت یا علاقه برای تدوین ویدئو و ساخت انیمیشن برا توضیح یه کانسپت و درگیری برای جذب سابسکرایبر یوتیوب رو ندارن.
ولی خب، چند وقتی یه بار یه کنفرانسی رو میان که صدای یه کتاب، یه شرکت، یه کامیونیتی یا... باشن، و به خاطر توانایی فنیشون انتخاب شدن که صحبت کنن نه قدرت مارکتینگ چنلشون.
- ریلیز نوت ها: پر از کلید واژه های مختلف و جذاب برای آنبورد شدن روی قابلیت های پروژه و آشنایی بیشتر با مفاهیم استفاده شده در اون.
- ایشو ها: مفصله، بعدا توضیح میدم.
- مقالات تخصصی
مقالاتی مثل این
https://dl.acm.org/doi/pdf/10.1145/3593856.3595909
یا مثلا وایت پیپر پروژه ها کلا تو یه لول دیگه اند ولی به عنوان مهندس باید از این مقالات بخونیم.
و البته مقالات تخصصی تر و آکادمیک تر که در چارچوب این پست نمیگنجه.
<<----->>
بازم مثل همیشه، مشتاق شنیدن انتقادات و نکات خوبی که بلدید هستیم. 🙌🏼🔥 | 962 |
