۹ عادت انسانهای ناموفق
موفقیت، نه یک لحظهی خاص که یک مسیرِ طولانی است که در آن تنها لحظاتی را برای جشن گرفتنِ تحقق هدفهایمان میایستیم و بعد دوباره برای رسیدن به هدفهای بعدی به راه میافتیم. در این مسیر طبیعتا نیازمند رهتوشهای هستیم که یکی از مهمترین اجزای آن، داشتن عادتهای درست است. عادت، یعنی کاری که بدون فکر و انگیزه در لحظه و بهصورت مستمر آن را انجام میدهیم. تکرار عادتهای درست، باعث میشوند تا حرکتِ ما بهسوی هدفهایمان تسریع و تسهیل شود؛ چرا که در واقع رسیدن به هدفها نیازمند به انجام کارهایی هستند که چیزی جز همین عادتهای درست نیستند! اما این سکه روی دیگری هم دارد. بسیاری از عادتهای نادرست هم وجود دارند که ما خواسته و ناخواسته گرفتار آنها هستیم و در مسیرمان بهسوی اهدافِ بزرگ زندگی، مانع ایجاد میکنند. بنابراین هر چقدر لازم است که عادتهای درست را بشناسیم و آنها را تقویت کنیم، بههمان اندازه لازم است که عادتهای بد را هم بشناسیم و برای حذف آنها از زندگیمان تلاش کنیم...
http://gozareha.com/1395/07/28/unsscfll-pppl-hbts/
موفقیت، نه یک لحظهی خاص که یک مسیرِ طولانی است که در آن تنها لحظاتی را برای جشن گرفتنِ تحقق هدفهایمان میایستیم و بعد دوباره برای رسیدن به هدفهای بعدی به راه میافتیم. در این مسیر طبیعتا نیازمند رهتوشهای هستیم که یکی از مهمترین اجزای آن، داشتن عادتهای درست است. عادت، یعنی کاری که بدون فکر و انگیزه در لحظه و بهصورت مستمر آن را انجام میدهیم. تکرار عادتهای درست، باعث میشوند تا حرکتِ ما بهسوی هدفهایمان تسریع و تسهیل شود؛ چرا که در واقع رسیدن به هدفها نیازمند به انجام کارهایی هستند که چیزی جز همین عادتهای درست نیستند! اما این سکه روی دیگری هم دارد. بسیاری از عادتهای نادرست هم وجود دارند که ما خواسته و ناخواسته گرفتار آنها هستیم و در مسیرمان بهسوی اهدافِ بزرگ زندگی، مانع ایجاد میکنند. بنابراین هر چقدر لازم است که عادتهای درست را بشناسیم و آنها را تقویت کنیم، بههمان اندازه لازم است که عادتهای بد را هم بشناسیم و برای حذف آنها از زندگیمان تلاش کنیم...
http://gozareha.com/1395/07/28/unsscfll-pppl-hbts/
گزارهها
۹ عادت انسانهای ناموفق
موفقیت، نه یک لحظهی خاص که یک مسیرِ طولانی است که در آن تنها لحظاتی را برای جشن گرفتنِ تحقق هدفهایمان میایستیم و بعد دوباره برای رسیدن به هدفهای بعدی به راه میافتیم. در این مسیر طبیعتا نیازمن…
یک ابزار آنلاین مناسب جهت رسم کردن انواع دیاگرام و فلوچارت و ...
💬 ابزارهای مختلفی رو تا به حال تست کردم که این از همه خوش دست تر و کاربردی تر بوده به نظرم بین بقیه. همچنین متن باز هست و میشه روی هاست های شخصی هم نصبش کرد.
https://www.draw.io/
💬 ابزارهای مختلفی رو تا به حال تست کردم که این از همه خوش دست تر و کاربردی تر بوده به نظرم بین بقیه. همچنین متن باز هست و میشه روی هاست های شخصی هم نصبش کرد.
https://www.draw.io/
app.diagrams.net
Flowchart Maker & Online Diagram Software
draw.io is a free online diagramming application and flowchart maker . You can use it to create UML, entity relationship,
org charts, BPMN and BPM, database schema and networks. Also possible are telecommunication network, workflow, flowcharts, maps overlays…
org charts, BPMN and BPM, database schema and networks. Also possible are telecommunication network, workflow, flowcharts, maps overlays…
💡 تفاوت بین برنامهنویس، هکر و توسعه دهنده
💬 البته به نظرم این تعاریف اغلب من در آوردی هست ولی از نگاه دیگه میتونه درست هم باشه
https://danielmiessler.com/study/programmer_hacker_developer
💬 البته به نظرم این تعاریف اغلب من در آوردی هست ولی از نگاه دیگه میتونه درست هم باشه
https://danielmiessler.com/study/programmer_hacker_developer
۱۰ مورد از اشتباهات رایج در برنامهنویسی که باید از آنها اجتناب کنید
«بهینه سازی زودرس»
به راحتی ممکن است دچار ضد الگوی بهینه سازی زودرس شویم، اگر به بهینه سازی ها و کارایی های کوچک در فرایند توسعه بیش از حد توجه کنیم و آن ها را زودتر از موعد بهینه کنیم قبل از این که بدانیم دقیقا قصد انجام چه کاری را داریم. طبق نقل قول معروف Donald Knuth "بهینه سازی زودرس ریشه همه بدی هاست". شاید کمی اغراق باشد ولی نشان می دهد ممکن است بعدها مشکلات بزرگتری را به وجود بیاورند.
برای جلوگیری از بهینه سازی زودرس، استفاده از قاعده برنامه نویسی YAGNI مخفف (You Aren’t Gonna Need It) مفید است به این معنی که «شما به آن نیازی نخواهید داشت» به طوری که این اصل حاکی از آن است که «همیشه چیزهایی را به کار ببرید که واقعا به آن ها نیاز دارید نه وقتی که پیش بینی می کنید به آن ها نیاز خواهید داشت.»
«برنامه نویسی بارپرستانه»
نام برنامه نویسی بار پرستانه از پدیده قومی خاصی به نام Cargo Cult به معنی «بارپرستی» گرفته شده است. بار پرستان که در جزایر اقیانوس آرام جنوبی زندگی می کردند، بعد از جنگ جهانی دوم، در مواجهه با تمدن های پیشرفته، کشتی هایی را دیده بودند که اجسام و بارهایی برای سفیدپوستان می آوردند از قبیل کوکاکولا، تلویزیون، یخچال و غیره که فکر کردند این بارها فرستاده نیروهای ماورائی است و اگر آن ها هم مناسک جادویی شبیه به کارهای غربی ها را به درستی انجام دهند، کشتی های باری دوباره خواهند آمد و به جای سفیدپوستان به آن ها هدیه خواهند داد.
وقتی مرتکب ضد الگوی برنامه نویسی بارپرستانه می شویم که در واقع داریم همین کار را انجام می دهیم. ما از فریمورک ها، لایبرری ها، راه حل ها، الگوهای طراحی و غیره استفاده می کنیم که برای کار دیگران به خوبی جواب داده اند، بدون این که بدانیم چرا باید از آن ها استفاده کنیم، یا این تکنولوژی ها دقیقا چگونه کار می کنند.
💬 مقاله ای که بخش هایی از اون رو مطالعه کردیم به نکات مفیدی اشاره میکنه که لازم هست برای نوشتن یک برنامه خوب به اونها توجه داشته باشیم. پیشنهاد میکنم متن کامل مقاله رو حتما در اینجا به طور کامل مطالعه بفرمائید.
«بهینه سازی زودرس»
به راحتی ممکن است دچار ضد الگوی بهینه سازی زودرس شویم، اگر به بهینه سازی ها و کارایی های کوچک در فرایند توسعه بیش از حد توجه کنیم و آن ها را زودتر از موعد بهینه کنیم قبل از این که بدانیم دقیقا قصد انجام چه کاری را داریم. طبق نقل قول معروف Donald Knuth "بهینه سازی زودرس ریشه همه بدی هاست". شاید کمی اغراق باشد ولی نشان می دهد ممکن است بعدها مشکلات بزرگتری را به وجود بیاورند.
برای جلوگیری از بهینه سازی زودرس، استفاده از قاعده برنامه نویسی YAGNI مخفف (You Aren’t Gonna Need It) مفید است به این معنی که «شما به آن نیازی نخواهید داشت» به طوری که این اصل حاکی از آن است که «همیشه چیزهایی را به کار ببرید که واقعا به آن ها نیاز دارید نه وقتی که پیش بینی می کنید به آن ها نیاز خواهید داشت.»
«برنامه نویسی بارپرستانه»
نام برنامه نویسی بار پرستانه از پدیده قومی خاصی به نام Cargo Cult به معنی «بارپرستی» گرفته شده است. بار پرستان که در جزایر اقیانوس آرام جنوبی زندگی می کردند، بعد از جنگ جهانی دوم، در مواجهه با تمدن های پیشرفته، کشتی هایی را دیده بودند که اجسام و بارهایی برای سفیدپوستان می آوردند از قبیل کوکاکولا، تلویزیون، یخچال و غیره که فکر کردند این بارها فرستاده نیروهای ماورائی است و اگر آن ها هم مناسک جادویی شبیه به کارهای غربی ها را به درستی انجام دهند، کشتی های باری دوباره خواهند آمد و به جای سفیدپوستان به آن ها هدیه خواهند داد.
وقتی مرتکب ضد الگوی برنامه نویسی بارپرستانه می شویم که در واقع داریم همین کار را انجام می دهیم. ما از فریمورک ها، لایبرری ها، راه حل ها، الگوهای طراحی و غیره استفاده می کنیم که برای کار دیگران به خوبی جواب داده اند، بدون این که بدانیم چرا باید از آن ها استفاده کنیم، یا این تکنولوژی ها دقیقا چگونه کار می کنند.
💬 مقاله ای که بخش هایی از اون رو مطالعه کردیم به نکات مفیدی اشاره میکنه که لازم هست برای نوشتن یک برنامه خوب به اونها توجه داشته باشیم. پیشنهاد میکنم متن کامل مقاله رو حتما در اینجا به طور کامل مطالعه بفرمائید.
«استارتآپ و ناگفته های بسیار»
💬 حرف هایی درباره مشکلات و موفقیت های «استارتآپ» که به نظر واقع بینانه تر از شلوغ کاری هایی میاد که در رسانه ها و تبلیغات شرکت ها اونها رو دیدیم. پیشنهاد میکنم اگر به این حوزه علاقهمند هستید این مقاله رو مطالعه کنید.
💬 حرف هایی درباره مشکلات و موفقیت های «استارتآپ» که به نظر واقع بینانه تر از شلوغ کاری هایی میاد که در رسانه ها و تبلیغات شرکت ها اونها رو دیدیم. پیشنهاد میکنم اگر به این حوزه علاقهمند هستید این مقاله رو مطالعه کنید.
استفاده از JOIN ها از نسخه ۳.۲ به بعد MongoDB
💬 یکی از ضعف هایی که به پایگاه داده MongoDB نسبت به دیتابیس های رابطهای وجود داشت، نداشتن امکان JOIN مناسب بین کالکشن ها بود که این ضعف از نسخه ۳.۲ به بعد MongoDB برطرف شده و به این دیتابیس قدرتمند NoSql اضافه شده.
🚩 برای کسب اطلاعات بیشتر میتونید این مقاله رو در این رابطه مطالعه کنید.
💬 یکی از ضعف هایی که به پایگاه داده MongoDB نسبت به دیتابیس های رابطهای وجود داشت، نداشتن امکان JOIN مناسب بین کالکشن ها بود که این ضعف از نسخه ۳.۲ به بعد MongoDB برطرف شده و به این دیتابیس قدرتمند NoSql اضافه شده.
🚩 برای کسب اطلاعات بیشتر میتونید این مقاله رو در این رابطه مطالعه کنید.
💡 نزدیک دو ساله که داریم روی یک سرویس تحت وب کار می کنیم، یادم میاد قبل از شروع کار یک ماه داشتیم طرح تجاری می نوشتیم و کلی هم تحقیقات بازار انجام دادیم، بعد از گذشت ۹ ماه که شروع کرده بودیم، دچار یک سردرگمی بدی شده بودیم، هم می دونستیم داریم چه کار می کنیم و هم نمی دونستیم، یه جای کار می لنگید، محصول اولیه آماده شده بود و باید وارد بازارش می کردیم ولی نمی تونستیم، مشکل بزرگی وجود داشت. چند وقتی ذهن ما را درگیر خودش کرده بود، احساس میکردیم چیزی که ساختیم نیازهای مشتری ما را برآورده نمی کنه، با وجودیکه در ابتدا باهاشون کلی صحبت کرده بودیم!
💬 متن بالا بخشی از مطلبی هست که «ابوالفضل فتاحی» درباره مشکلی که با محصولشون داشتند و اینکه چطور حلش کردند در وبلاگش نوشته. من هم چون با همچین مشکلی مساله داشتم به نظرم رسید مطلبش رو اینجا هم بگذارم تا شاید برای دیگران هم مفید باشه و در ادامه هم کتاب «آزمونِ مامان» رو در همین رابطه معرفی کرده که فکر کنم لازمه در اولین فرصت بگیرم و بخونمش.
💬 متن بالا بخشی از مطلبی هست که «ابوالفضل فتاحی» درباره مشکلی که با محصولشون داشتند و اینکه چطور حلش کردند در وبلاگش نوشته. من هم چون با همچین مشکلی مساله داشتم به نظرم رسید مطلبش رو اینجا هم بگذارم تا شاید برای دیگران هم مفید باشه و در ادامه هم کتاب «آزمونِ مامان» رو در همین رابطه معرفی کرده که فکر کنم لازمه در اولین فرصت بگیرم و بخونمش.
یه منبع خوب و جمع و جور برای اونهایی که میخواهن بیشتر با لینوکس آشنا بشن 😊
🌐 https://linuxjourney.com
🌐 https://linuxjourney.com
مجموعه ای از کتاب های رایگان جمع آوری شده برای توسعه دهندگان و برنامه نویسان
💬 راه اندازی چنین صفحه ای برای کتاب های رایگان فارسی موجود هم کار خوب و مفیدی هست اگر کسی حالش رو داشته باشه 😊
https://devfreebooks.github.io
💬 راه اندازی چنین صفحه ای برای کتاب های رایگان فارسی موجود هم کار خوب و مفیدی هست اگر کسی حالش رو داشته باشه 😊
https://devfreebooks.github.io
امروز جمله ای از یک دانشمند علوم کامپیوتر به نام «Donald Knuth» دیدم که به نظرم جمله مهمی هست:
«بهینه سازی قبل از موقع ریشه تمام شر ها است.»
برداشت من از این جمله این هست که قبل از اینکه برنامه رو به نقطه ای برسونیم که کار کنه شروع کنیم به بهینهسازی در قسمت های مختلف مثل بهینه سازی کدها، که شاید به خاطر وسواس ما به بهینه بودن باشه اما این میتونه زیان هایی هم داشته باشه که مهمترینش «از دست دادن زمان» هست. چرا که ممکنه شما کدی رو بهینه سازی کنید که وقتی جلو تر برید به این نتیجه برسید که باید تغییر کنه یا اصلا حذف بشه!
پس اگر «زمان» توی پروژه هامون فاکتور مهمی هست که هست، باید حواسمون به این نکته هم باشه ☕
«بهینه سازی قبل از موقع ریشه تمام شر ها است.»
برداشت من از این جمله این هست که قبل از اینکه برنامه رو به نقطه ای برسونیم که کار کنه شروع کنیم به بهینهسازی در قسمت های مختلف مثل بهینه سازی کدها، که شاید به خاطر وسواس ما به بهینه بودن باشه اما این میتونه زیان هایی هم داشته باشه که مهمترینش «از دست دادن زمان» هست. چرا که ممکنه شما کدی رو بهینه سازی کنید که وقتی جلو تر برید به این نتیجه برسید که باید تغییر کنه یا اصلا حذف بشه!
پس اگر «زمان» توی پروژه هامون فاکتور مهمی هست که هست، باید حواسمون به این نکته هم باشه ☕
«فرآیند تست نرمافزار؛ یک انتخاب یا یک ضرورت؟» (متن کامل مقاله)
💡 وجود فرآیند تست نرمافزار معمولاً نیاز به هزینه و زمان زیادی داره، اما باید این نکته رو هم درنظر بگیریم که بیشتر محصولات نرمافزاری سطح متوسط و سطح عظیم، در صورتی که بدون انجام تستهای کیفی وارد فاز اجرایی بشند، میتونند هزینه و خسارتهای کلان و گاهاً جبران ناپذیری وارد کنند؛ برای نمونه میشه به چند مورد بارز اشاره کرد:
🔅سازمان درآمد داخلی امریکا (سال ۲۰۰۶ میلادی)
دلیل خطا: عدم وجود سیستم تشخیص تقلب و لاگ نشدن دادهها در پرتال سازمان
نتیجه: ایجاد اختلال غیرقابل ردگیری در حسابهای مالی (خسارت ۳۰۰ میلیون دلاری)
🔅سفینهٔ فضایی Mariner 1 (سال ۱۹۶۲ میلادی)
دلیل خطا: اشتباه برنامهنویس در وارد کردن فرمول محاسباتی و جا انداختن تنها یک پارامتر در فرمول
نتیجه: انحراف و بروز انفجار پس از ۲۹۳ ثانیه از شروع (خسارت ۱۹ میلیون دلاری)
🔅پروژهٔ استارتآپ GoZoomo (سال ۲۰۱۴ تا ۲۰۱۶ میلادی)
دلیل خطا: اشتباه در طرح اولیه سیستم و ادامهٔ مسیر توسعه با همان مدل نادرست
نتیجه: تعطیل شدن پروژه پس از حدود ۲ سال فعالیت بیش از ۶۵ نفر (خسارت تقریبی ۳ میلیون دلاری)
🔅باگ FDIV در پردازندهٔ پنتیوم اینتل (سال ۱۹۴۴ میلادی)
خطا: ایراد در فرمول محاسبهٔ اعداد اعشاری و برگرداندن نتایج نادرست در مواقعی خاص
نتیجه: اعلام خرابی و جمعآوری ۵ میلیون پردازنده (خسارت ۴۷۵ میلیون دلاری و کاهش اعتبار برند)
🔅دستگاه رادیوتراپی Therac-25 (سال ۱۹۴۴ میلادی)
خطا: اشتباه جزئی در تعریف حلقه و دوبرابر شدن مقدار داده در شرایط خاص
نتیجه: استفاده از دز نامناسب برای برخی بیماران (مرگ ۱۰ نفر و ۲۰ صدمهٔ فیزیکی غیرقابل جبران)
💡 وجود فرآیند تست نرمافزار معمولاً نیاز به هزینه و زمان زیادی داره، اما باید این نکته رو هم درنظر بگیریم که بیشتر محصولات نرمافزاری سطح متوسط و سطح عظیم، در صورتی که بدون انجام تستهای کیفی وارد فاز اجرایی بشند، میتونند هزینه و خسارتهای کلان و گاهاً جبران ناپذیری وارد کنند؛ برای نمونه میشه به چند مورد بارز اشاره کرد:
🔅سازمان درآمد داخلی امریکا (سال ۲۰۰۶ میلادی)
دلیل خطا: عدم وجود سیستم تشخیص تقلب و لاگ نشدن دادهها در پرتال سازمان
نتیجه: ایجاد اختلال غیرقابل ردگیری در حسابهای مالی (خسارت ۳۰۰ میلیون دلاری)
🔅سفینهٔ فضایی Mariner 1 (سال ۱۹۶۲ میلادی)
دلیل خطا: اشتباه برنامهنویس در وارد کردن فرمول محاسباتی و جا انداختن تنها یک پارامتر در فرمول
نتیجه: انحراف و بروز انفجار پس از ۲۹۳ ثانیه از شروع (خسارت ۱۹ میلیون دلاری)
🔅پروژهٔ استارتآپ GoZoomo (سال ۲۰۱۴ تا ۲۰۱۶ میلادی)
دلیل خطا: اشتباه در طرح اولیه سیستم و ادامهٔ مسیر توسعه با همان مدل نادرست
نتیجه: تعطیل شدن پروژه پس از حدود ۲ سال فعالیت بیش از ۶۵ نفر (خسارت تقریبی ۳ میلیون دلاری)
🔅باگ FDIV در پردازندهٔ پنتیوم اینتل (سال ۱۹۴۴ میلادی)
خطا: ایراد در فرمول محاسبهٔ اعداد اعشاری و برگرداندن نتایج نادرست در مواقعی خاص
نتیجه: اعلام خرابی و جمعآوری ۵ میلیون پردازنده (خسارت ۴۷۵ میلیون دلاری و کاهش اعتبار برند)
🔅دستگاه رادیوتراپی Therac-25 (سال ۱۹۴۴ میلادی)
خطا: اشتباه جزئی در تعریف حلقه و دوبرابر شدن مقدار داده در شرایط خاص
نتیجه: استفاده از دز نامناسب برای برخی بیماران (مرگ ۱۰ نفر و ۲۰ صدمهٔ فیزیکی غیرقابل جبران)
Terminal forever 😊
اگر از این مدل کمیک استریپ های دولوپری طور خوشتون میاد پیشنهاد میکنم یه نگاه به این سایت بندازید برای رفع خستگی خوبه ☕️
http://www.commitstrip.com/
اگر از این مدل کمیک استریپ های دولوپری طور خوشتون میاد پیشنهاد میکنم یه نگاه به این سایت بندازید برای رفع خستگی خوبه ☕️
http://www.commitstrip.com/
💬 امروز مقاله ای خوندم با عنوان «شی گرایی، از حرف تا عمل» که جناب آقای امیر رضا قادری نوشته و در وبلاگش منتشر کرده.
توی این مقاله توضیحات خوبی درباره مدل صحیح برنامه نویسی فانکشنال که در زبان های گولنگ و لیسپ وجود داره و این روزها هم تب داغی داره و همچنین درباره مدل صحیح برنامه نویسی شی گرا مطالب خوبی آورده شده که اگر برنامه نویس هستید براتون قابل تأمل خواهد بود و پیشنهاد میکنم حتما این مقاله رو مطالعه کنید.
قسمت هایی از مقاله:
برنامهنویسی فانکشنال رو میشه در یک جمله تعریف کرد:
«برنامهنویسی فانکشنال مدلی از برنامهنویسی است که در آن عمل تخصیص مقادیر وجود ندارد.»
اینجا میتونیم یه تعریف دیگه هم از برنامهنویسی فانکشنال ارائه بدیم:
«برنامهنویسی فانکشنال مدلی از برنامهنویسی است که در آن همه چیز یک تابع است»
توی این مقاله توضیحات خوبی درباره مدل صحیح برنامه نویسی فانکشنال که در زبان های گولنگ و لیسپ وجود داره و این روزها هم تب داغی داره و همچنین درباره مدل صحیح برنامه نویسی شی گرا مطالب خوبی آورده شده که اگر برنامه نویس هستید براتون قابل تأمل خواهد بود و پیشنهاد میکنم حتما این مقاله رو مطالعه کنید.
قسمت هایی از مقاله:
برنامهنویسی فانکشنال رو میشه در یک جمله تعریف کرد:
«برنامهنویسی فانکشنال مدلی از برنامهنویسی است که در آن عمل تخصیص مقادیر وجود ندارد.»
اینجا میتونیم یه تعریف دیگه هم از برنامهنویسی فانکشنال ارائه بدیم:
«برنامهنویسی فانکشنال مدلی از برنامهنویسی است که در آن همه چیز یک تابع است»
amirrezaghaderi.ir
شی گرایی، از حرف تا عمل | وب نوشتها | امیررضا قادری
تقابل شی گرایی و برنامه نویسی فانکشنال
۲۰۱۷ سالی هست که توسعهدهندگان فرانت اند باید به عقب برگردند و اصول پایه رو فرا بگیرند
💬 این عنوان مقاله ای هست که در ادامه به برخی عناوینش به صورت تیتر وار اشاره میکنم و اگر توسعه دهنده فرانت هستید پیشنهاد میکنم به این مقاله نگاهی بیاندازید.
- یاد بگیرید چطور کد خوانا بنویسید
- جاوااسکریپت رو عمیق تر یاد بگیرید
- برنامه نویسی فانکشنال رو یاد بگیرید
- اصول طراحی رو یاد بگیرید
- یاد بگیرید چطور با آدمها کار کنید
- یاد بگیرید چطور برای انسان ها کد بنویسید
💬 این عنوان مقاله ای هست که در ادامه به برخی عناوینش به صورت تیتر وار اشاره میکنم و اگر توسعه دهنده فرانت هستید پیشنهاد میکنم به این مقاله نگاهی بیاندازید.
- یاد بگیرید چطور کد خوانا بنویسید
- جاوااسکریپت رو عمیق تر یاد بگیرید
- برنامه نویسی فانکشنال رو یاد بگیرید
- اصول طراحی رو یاد بگیرید
- یاد بگیرید چطور با آدمها کار کنید
- یاد بگیرید چطور برای انسان ها کد بنویسید
freeCodeCamp
2017 is the year that front-end developers should go back and master the basics
With our fast-paced ecosystem we tend to spend our time trying the latest inventions. Probably we should slow down a bit.
۵ عامل عدم موفقیت از نظر موسس گروه سولیکو(کاله)
۱. نبود اعتماد
نبود اعتماد، مشکلی است که گریبان همه را گرفته است. مدیر نمیخواهد به زیر دستش اعتماد کند و دست او را برای گرفتن تصمیم و دست به عمل زدن باز بگذارد.
۲. ترس از برخورد
بسیاری از افراد از اینکه با آنها برخورد شود میترسند. میترسند کاری بکنند و شکست بخورند و همکاران آنها با آنها برخورد کنند. همین عامل باعث میشود که دست به هیچ کاری نزنند. نباید ترسید. باید اقدام کرد. باید دست به عمل زد و از برخورد نترسید.
۳. نبود تعهد
افراد نسبت به کاری که باید انجام دهند تعهد ندارند. فکر میکنند تنها بخشی از کار که در شرح شغل آنها آمده است به آنها مربوط است. این در حالی است که فرد متعهد کسی است که دیدگاه حل مسئله دارد و تصمیم دارد مسئله را حل کند و کاری هم به شرح شغل و حیطه وظایف ندارد.
۴. پرهیز از مسئولیت پذیری
افراد از اینکه مسئولیت کاری را بپذیرند میترسند ولی برای موفقیت باید هر فردی درجه بالایی از مسئولیت پذیری را داشته باشد.
۵. بیتوجهی به نتیجه کار
باید به نتیجه کار توجه کرد. باید بررسی کرد که با تمام اقداماتی که انجام میدهیم در نهایت چه نتایجی حاصل خواهد شد.
منبع: وبلاگ مصطفی لامعی
۱. نبود اعتماد
نبود اعتماد، مشکلی است که گریبان همه را گرفته است. مدیر نمیخواهد به زیر دستش اعتماد کند و دست او را برای گرفتن تصمیم و دست به عمل زدن باز بگذارد.
۲. ترس از برخورد
بسیاری از افراد از اینکه با آنها برخورد شود میترسند. میترسند کاری بکنند و شکست بخورند و همکاران آنها با آنها برخورد کنند. همین عامل باعث میشود که دست به هیچ کاری نزنند. نباید ترسید. باید اقدام کرد. باید دست به عمل زد و از برخورد نترسید.
۳. نبود تعهد
افراد نسبت به کاری که باید انجام دهند تعهد ندارند. فکر میکنند تنها بخشی از کار که در شرح شغل آنها آمده است به آنها مربوط است. این در حالی است که فرد متعهد کسی است که دیدگاه حل مسئله دارد و تصمیم دارد مسئله را حل کند و کاری هم به شرح شغل و حیطه وظایف ندارد.
۴. پرهیز از مسئولیت پذیری
افراد از اینکه مسئولیت کاری را بپذیرند میترسند ولی برای موفقیت باید هر فردی درجه بالایی از مسئولیت پذیری را داشته باشد.
۵. بیتوجهی به نتیجه کار
باید به نتیجه کار توجه کرد. باید بررسی کرد که با تمام اقداماتی که انجام میدهیم در نهایت چه نتایجی حاصل خواهد شد.
منبع: وبلاگ مصطفی لامعی
بعضی وقتا بعضی چیزها به همین مسخره گی اتفاق میافته درست مثل همون ۳۶ میلیون اکانتی که رفت رو هوا
https://www.hackread.com/hacker-leaks-36-million-mongodb-accounts/
https://www.hackread.com/hacker-leaks-36-million-mongodb-accounts/
Hackread - Latest Cybersecurity News, Press Releases & Technology Today
Hackers Leak 36 million+ MongoDB Accounts
You may have heard of the phrase It's raining cats and dogs but in the world of cyber security it's raining data!