نکته های خواندنی - علی ایرانی 📖
92 subscribers
33 photos
2 videos
1 file
150 links
📖 نکته های خواندنی از نگاه علی ایرانی

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

🆔 @airani
ℹ️ https://irani.im
Download Telegram
یک ابزار آنلاین مناسب جهت رسم کردن انواع دیاگرام و فلوچارت و ...

💬 ابزارهای مختلفی رو تا به حال تست کردم که این از همه خوش دست تر و کاربردی تر بوده به نظرم بین بقیه. همچنین متن باز هست و میشه روی هاست های شخصی هم نصبش کرد.

https://www.draw.io/
💡 تفاوت بین برنامه‌نویس، هکر و توسعه دهنده

💬 البته به نظرم این تعاریف اغلب من در آوردی هست ولی از نگاه دیگه میتونه درست هم باشه

https://danielmiessler.com/study/programmer_hacker_developer
 ۱۰ مورد از اشتباهات رایج در برنامه‌نویسی که باید از آنها اجتناب کنید

«بهینه سازی زودرس»
به راحتی ممکن است دچار ضد الگوی بهینه سازی زودرس شویم، اگر به بهینه سازی ها و کارایی های کوچک در فرایند توسعه بیش از حد توجه کنیم و آن ها را زودتر از موعد بهینه کنیم قبل از این که بدانیم دقیقا قصد انجام چه کاری را داریم. طبق نقل قول معروف Donald Knuth "بهینه سازی زودرس ریشه همه بدی هاست". شاید کمی اغراق باشد ولی نشان می دهد ممکن است بعدها مشکلات بزرگتری را به وجود بیاورند.
برای جلوگیری از بهینه سازی زودرس، استفاده از قاعده برنامه نویسی YAGNI مخفف (You Aren’t Gonna Need It) مفید است به این معنی که «شما به آن نیازی نخواهید داشت» به طوری که این اصل حاکی از آن است که «همیشه چیزهایی را به کار ببرید که واقعا به آن ها نیاز دارید نه وقتی که پیش بینی می کنید به آن ها نیاز خواهید داشت.»

«برنامه نویسی بارپرستانه»
نام برنامه نویسی بار پرستانه از پدیده قومی خاصی به نام Cargo Cult به معنی «بارپرستی» گرفته شده است. بار پرستان که در جزایر اقیانوس آرام جنوبی زندگی می کردند، بعد از جنگ جهانی دوم، در مواجهه با تمدن های پیشرفته، کشتی هایی را دیده بودند که اجسام و بارهایی برای سفیدپوستان می آوردند از قبیل کوکاکولا، تلویزیون، یخچال و غیره که فکر کردند این بارها فرستاده نیروهای ماورائی است و اگر آن ها هم مناسک جادویی شبیه به کارهای غربی ها را به درستی انجام دهند، کشتی های باری دوباره خواهند آمد و به جای سفیدپوستان به آن ها هدیه خواهند داد.
وقتی مرتکب ضد الگوی برنامه نویسی بارپرستانه می شویم که در واقع داریم همین کار را انجام می دهیم. ما از فریمورک ها، لایبرری ها، راه حل ها، الگوهای طراحی و غیره استفاده می کنیم که برای کار دیگران به خوبی جواب داده اند، بدون این که بدانیم چرا باید از آن ها استفاده کنیم، یا این تکنولوژی ها دقیقا چگونه کار می کنند.

💬 مقاله ای که بخش هایی از اون رو مطالعه کردیم به نکات مفیدی اشاره میکنه که لازم هست برای نوشتن یک برنامه خوب به اونها توجه داشته باشیم. پیشنهاد میکنم متن کامل مقاله رو حتما در اینجا به طور کامل مطالعه بفرمائید.
«استارت‌آپ و ناگفته های بسیار»

💬 حرف هایی درباره مشکلات و موفقیت های «استارت‌آپ» که به نظر واقع بینانه تر از شلوغ کاری هایی میاد که در رسانه ها و تبلیغات شرکت ها اونها رو دیدیم. پیشنهاد میکنم اگر به این حوزه علاقه‌مند هستید این مقاله رو مطالعه کنید.
 استفاده از JOIN ها از نسخه ۳.۲ به بعد MongoDB

💬 یکی از ضعف هایی که به پایگاه داده MongoDB نسبت به دیتابیس های رابطه‌ای وجود داشت، نداشتن امکان JOIN مناسب بین کالکشن ها بود که این ضعف از نسخه ۳.۲ به بعد MongoDB برطرف شده و به این دیتابیس قدرتمند NoSql اضافه شده.

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

💬 متن بالا بخشی از مطلبی هست که «ابوالفضل فتاحی» درباره مشکلی که با محصولشون داشتند و اینکه چطور حلش کردند در وبلاگش نوشته. من هم چون با همچین مشکلی مساله داشتم به نظرم رسید مطلبش رو اینجا هم بگذارم تا شاید برای دیگران هم مفید باشه و در ادامه هم کتاب «آزمونِ مامان» رو در همین رابطه معرفی کرده که فکر کنم لازمه در اولین فرصت بگیرم و بخونمش.
یه منبع خوب و جمع و جور برای اونهایی که میخواهن بیشتر با لینوکس آشنا بشن 😊

🌐 https://linuxjourney.com
 مجموعه ای از کتاب های رایگان جمع آوری شده برای توسعه دهندگان و برنامه نویسان

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

https://devfreebooks.github.io
شاید حال و روز خیلی از ما با پروژه هامون
 امروز جمله ای از یک دانشمند علوم کامپیوتر به نام «Donald Knuth» دیدم که به نظرم جمله مهمی هست:

«بهینه سازی قبل از موقع ریشه تمام شر ها است.»

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

پس اگر «زمان» توی پروژه هامون فاکتور مهمی هست که هست، باید حواسمون به این نکته هم باشه
 «فرآیند تست نرم‌افزار؛ یک انتخاب یا یک ضرورت؟» (متن کامل مقاله)

💡 وجود فرآیند تست نرم‌افزار معمولاً نیاز به هزینه و زمان زیادی داره، اما باید این نکته رو هم درنظر بگیریم که بیشتر محصولات نرم‌افزاری سطح متوسط و سطح عظیم، در صورتی که بدون انجام تست‌های کیفی وارد فاز اجرایی بشند، میتونند هزینه‌ و خسارت‌های کلان و گاهاً جبران ناپذیری وارد کنند؛ برای نمونه میشه به چند مورد بارز اشاره کرد:

🔅سازمان درآمد داخلی امریکا (سال ۲۰۰۶ میلادی)
دلیل خطا: عدم وجود سیستم تشخیص تقلب و لاگ نشدن داده‌ها در پرتال سازمان
نتیجه: ایجاد اختلال غیرقابل ردگیری در حساب‌های مالی (خسارت ۳۰۰ میلیون دلاری)

🔅سفینهٔ فضایی Mariner 1 (سال ۱۹۶۲ میلادی)
دلیل خطا: اشتباه برنامه‌نویس در وارد کردن فرمول محاسباتی و جا انداختن تنها یک پارامتر در فرمول
نتیجه: انحراف و بروز انفجار پس از ۲۹۳ ثانیه از شروع (خسارت ۱۹ میلیون دلاری)

🔅پروژهٔ استارت‌آپ GoZoomo (سال ۲۰۱۴ تا ۲۰۱۶ میلادی)
دلیل خطا: اشتباه در طرح اولیه سیستم و ادامهٔ مسیر توسعه با همان مدل نادرست
نتیجه: تعطیل شدن پروژه پس از حدود ۲ سال فعالیت بیش از ۶۵ نفر (خسارت تقریبی ۳ میلیون دلاری)

🔅باگ FDIV در پردازندهٔ پنتیوم اینتل (سال ۱۹۴۴ میلادی)
خطا: ایراد در فرمول محاسبهٔ اعداد اعشاری و برگرداندن نتایج نادرست در مواقعی خاص
نتیجه: اعلام خرابی و جمع‌آوری ۵ میلیون پردازنده (خسارت ۴۷۵ میلیون دلاری و کاهش اعتبار برند)

🔅دستگاه رادیوتراپی Therac-25 (سال ۱۹۴۴ میلادی)
خطا: اشتباه جزئی در تعریف حلقه و دوبرابر شدن مقدار داده در شرایط خاص
نتیجه: استفاده از دز نامناسب برای برخی بیماران (مرگ ۱۰ نفر و ۲۰ صدمهٔ فیزیکی غیرقابل جبران)
Terminal forever 😊

اگر از این مدل کمیک استریپ های دولوپری طور خوشتون میاد پیشنهاد می‌کنم یه نگاه به این سایت بندازید برای رفع خستگی خوبه ☕️

http://www.commitstrip.com/
💬 امروز مقاله ای خوندم با عنوان «شی گرایی، از حرف تا عمل» که جناب آقای امیر رضا قادری نوشته و در وبلاگش منتشر کرده.

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

قسمت هایی از مقاله:

برنامه‌نویسی فانکشنال رو میشه در یک جمله تعریف کرد:
«برنامه‌نویسی فانکشنال مدلی از برنامه‌نویسی است که در آن عمل تخصیص مقادیر وجود ندارد.»

اینجا می‌تونیم یه تعریف دیگه هم از برنامه‌نویسی فانکشنال ارائه بدیم:
«برنامه‌نویسی فانکشنال مدلی از برنامه‌نویسی است که در آن همه چیز یک تابع است»
۲۰۱۷ سالی هست که توسعه‌دهندگان فرانت اند باید به عقب برگردند و اصول پایه رو فرا بگیرند

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

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

۱. نبود اعتماد
نبود اعتماد، مشکلی است که گریبان همه را گرفته است. مدیر نمی‌خواهد به زیر دستش اعتماد کند و دست او را برای گرفتن تصمیم و دست به عمل زدن باز بگذارد.

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

۳. نبود تعهد
افراد نسبت به کاری که باید انجام دهند تعهد ندارند. فکر می‌کنند تنها بخشی از کار که در شرح شغل آنها آمده است به آنها مربوط است. این در حالی است که فرد متعهد کسی است که دیدگاه حل مسئله دارد و تصمیم دارد مسئله را حل کند و کاری هم به شرح شغل و حیطه وظایف ندارد.

۴. پرهیز از مسئولیت پذیری
افراد از اینکه مسئولیت کاری را بپذیرند می‌ترسند ولی برای موفقیت باید هر فردی درجه بالایی از مسئولیت پذیری را داشته باشد.

۵. بی‌توجهی به نتیجه کار
باید به نتیجه کار توجه کرد. باید بررسی کرد که با تمام اقداماتی که انجام می‌دهیم در نهایت چه نتایجی حاصل خواهد شد.

منبع: وبلاگ مصطفی لامعی
اگر میخواهید یک بار برای همیشه ۰ تا ۱۰۰ #FlexBox رو در #CSS متوجه بشید پیشنهاد می‌کنم این مقاله کامل و طولانی رو تا انتها و با دقت مطالعه کنید.

اینجا هم یکسری نمونه از کارهایی که قبلا در CSS انجامش سخت بود و حالا با FlexBox آسون شده رو جمع آوری کرده.

☕️ @airaniTips
کد خوب مثل جک خوب می‌مونه، نیاز به توضیح نداره 😊

☕️ @airaniTips
 اگر با چالش استخدام برنامه‌نویس روبه‌رو هستید و علاقه‌مندید تجربه و نکات دیگران رو در این خصوص داشته باشید پیشنهاد می‌کنم مقاله مفیدِ دوست خوبم حامد تکمیل رو در وبلاگش مطالعه کنید. حامد توی این مقاله با زبانی خودمانی مستقیم رفته سر اصل مطلب و به نکات خوبی اشاره کرده که برخی از اونها رو در ادامه آوردم:

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

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

«وقتی آگهی بلند بالا با اون همه تخصص میزنی، نیرو می ترسه، فرار می کنه.»

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

☕️ @airaniTips