Between a monarchy and the most democratic republic there is only one essential difference: in the former, the world of officialdom oppresses and robs the people for the greater profit of the privileged and propertied classes, as well as to line its own pockets, in the name of the monarch; in the latter, it oppresses and robs the people in exactly the same way, for the benefit of the same classes and the same pockets, but in the name of the people’s will. In a republic a fictitious people, the ‘legal nation’ supposedly represented by the state, smothers the real, live people. But it will scarcely be any easier on the people if the cudgel with which they are beaten is called the people’s cudgel (Bakunin 1990, 23).
❤3✍2💋1
Forwarded from فلسفه
🎞 دیالوگ های ماندگار سریال تاریکی (Dark)
▪️میکل نیلسن: اوضاع فقط وقتی تغییر می کنه که ما اونا رو تغییر بدیم، اما تو مجبوری این کارو بکنی.
▪️اچ.جی تانهاوس: تفکر ما با دوگانه گرایی شکل گرفته: ورود و خروج. سیاه و سفید، خوب و بد. هر چیزی به صورت دو جفت متضاد هم ظاهر می شه اما این اشتباهه.
▪️نوح: اکثر مردم چیزی نیستن به جز سربازان پیاده یه صفحه شطرنج که با یه دست ناشناخته هدایت می شن.
▪️مارتا: همه ما با یه پایان یکسان روبرو هستیم.
▪️غریبه: در پایان همه ما همون چیزی رو دریافت می کنیم که شایسته اون هستیم.
▪️پسر اوا: جهنم خالیه، همه شیاطین این جا هستن.
▪️آدام: فقط وقتی خودمون رو از احساسات خلاص کنیم می تونیم واقعا آزاد باشیم، وقتی که راضی بشیم عزیزترین چیز خودمون رو فدا کنیم.
▪️نوح: ترس بدترین دشمن پیشرفته.
▪️غریبه: دیروز، امروز و فردا پشت سر هم نیستن بلکه به صورت یه حلقه بدون پایان به هم متصل شدن، همه چیز به هم وصله.
▪️مارتا: در پایان، هر مرگ فقط یه شروع جدیده.
▪️پدر تانهاوس پیر: هر چیزی که یه زمانی زندگی می کرده برای همیشه زنده اس، در ابدیت زمان.
▪️جوناس: زندگی یه هدیه س برای کسانی که می دونن چطور ازش استفاده کنن.
▪️مارتا: اشتباهی که در همه تفکرات ما وجود داره اینه که هر یک از ما معتقدیم موجودی مستقلیم، اما واقعیت اینه که همه ما تنها کسر کوچکی از یه مجموعه بی نهایت هستیم.
▪️غریبه: خدا برای هر انسان برنامه ای داره.
▪️میکل نیلسن: چیزی به اسم جادو وجود نداره، فقط توهمه.
▪️اینس کانوالد: درباره پارادوکس استاد جوانگ چیزی شنیدی؟ “خواب دیدم پروانه هستم. حالا که از خواب بیدار شدم دیگر نمی دانم کسی هستم که خواب دیده پروانه شده یا پروانه ای هستم که رویای آدم شدن رو می بینم.”
▪️غریبه: اگه همین الان گذشته خودم رو تغییر بدم، اون چیزی که الان هستم رو تغییر خواهم داد.
▪️نوح: زندگی چیزی جز مارپیچی از درد نیست.
▪️آدام: چیزی که می دونیم یه قطره اس، چیزی که نمی دونیم یه اقیانوسه.
▪️جوناس و مارتا: من و تو برای همدیگه ساخته شدیم، هرگز چیزی غیر از اینو باور نکن.
join us | کانال فلسفه
@Philosophy3
▪️میکل نیلسن: اوضاع فقط وقتی تغییر می کنه که ما اونا رو تغییر بدیم، اما تو مجبوری این کارو بکنی.
▪️اچ.جی تانهاوس: تفکر ما با دوگانه گرایی شکل گرفته: ورود و خروج. سیاه و سفید، خوب و بد. هر چیزی به صورت دو جفت متضاد هم ظاهر می شه اما این اشتباهه.
▪️نوح: اکثر مردم چیزی نیستن به جز سربازان پیاده یه صفحه شطرنج که با یه دست ناشناخته هدایت می شن.
▪️مارتا: همه ما با یه پایان یکسان روبرو هستیم.
▪️غریبه: در پایان همه ما همون چیزی رو دریافت می کنیم که شایسته اون هستیم.
▪️پسر اوا: جهنم خالیه، همه شیاطین این جا هستن.
▪️آدام: فقط وقتی خودمون رو از احساسات خلاص کنیم می تونیم واقعا آزاد باشیم، وقتی که راضی بشیم عزیزترین چیز خودمون رو فدا کنیم.
▪️نوح: ترس بدترین دشمن پیشرفته.
▪️غریبه: دیروز، امروز و فردا پشت سر هم نیستن بلکه به صورت یه حلقه بدون پایان به هم متصل شدن، همه چیز به هم وصله.
▪️مارتا: در پایان، هر مرگ فقط یه شروع جدیده.
▪️پدر تانهاوس پیر: هر چیزی که یه زمانی زندگی می کرده برای همیشه زنده اس، در ابدیت زمان.
▪️جوناس: زندگی یه هدیه س برای کسانی که می دونن چطور ازش استفاده کنن.
▪️مارتا: اشتباهی که در همه تفکرات ما وجود داره اینه که هر یک از ما معتقدیم موجودی مستقلیم، اما واقعیت اینه که همه ما تنها کسر کوچکی از یه مجموعه بی نهایت هستیم.
▪️غریبه: خدا برای هر انسان برنامه ای داره.
▪️میکل نیلسن: چیزی به اسم جادو وجود نداره، فقط توهمه.
▪️اینس کانوالد: درباره پارادوکس استاد جوانگ چیزی شنیدی؟ “خواب دیدم پروانه هستم. حالا که از خواب بیدار شدم دیگر نمی دانم کسی هستم که خواب دیده پروانه شده یا پروانه ای هستم که رویای آدم شدن رو می بینم.”
▪️غریبه: اگه همین الان گذشته خودم رو تغییر بدم، اون چیزی که الان هستم رو تغییر خواهم داد.
▪️نوح: زندگی چیزی جز مارپیچی از درد نیست.
▪️آدام: چیزی که می دونیم یه قطره اس، چیزی که نمی دونیم یه اقیانوسه.
▪️جوناس و مارتا: من و تو برای همدیگه ساخته شدیم، هرگز چیزی غیر از اینو باور نکن.
join us | کانال فلسفه
@Philosophy3
👍9❤🔥3🗿2✍1
بازی زندگی کانوی
بازی زندگی کانوی (به انگلیسی: Conway's Game of Life) یا بازی زندگی یا بهطور مختصر زندگی (Life)، یک اتوماتای سلولی است که توسط ریاضیدان انگلیسی جان هورتون کانوی در سال ۱۹۷۰ میلادی به وجود آمد. بازی زندگی مشهورترین نمونه یک اتوماتای سلولی است.
زندگی یک بازی بدون بازیکن است، بدین معنا که تکامل آن تنها وابسته به وضعیت و شرایط آغازین آن بوده و نیازی به عامل ورودی انسانی در مراحل بعد ندارد. نحوه تراکنش انسانی با بازی بدین صورت است که فرد در شروع بازی حالت ابتدایی چیدمان را به وجود میآورد و سپس چگونگی رشد و تکامل سیستم را بدون دخالت خود مشاهده میکند.
دنیای بازی زندگی از یک جدول نامتناهی دو بعدی با بردارهای متعامد ساخته شدهاست که شامل سلولهای مربع شکل است. هر سلول میتواند یکی از دو حالت زنده یا مرده را داشته باشد. هر سلول با هشت سلول همسایه و همجوار خود به صورت افقی، عمودی و مورب، در تراکنش است. در هر مرحله زمانی از بازی، تحولات زیر اتفاق میافتند:
۱. هر سلول زنده با کمتر از ۲ همسایه زنده، میمیرد. (به دلیل کمبود جمعیت)
۲. هر سلول زنده با بیش از ۳ همسایه زنده، میمیرد. (به دلیل ازدحام جمعیت)
۳. هر سلول زنده با ۲ یا ۳ همسایه زنده، زنده میماند و به نسل بعد میرود.
۴. هر سلول مرده با دقیقاً ۳ همسایه زنده، دوباره زنده میشود.
الگوی آغازین بازی به عنوان بذر سیستم به حساب میآید. اولین نسل در بازی با اعمال قوانین فوق بر تک تک سلولها به صورت همزمان ایجاد میشود و در آن زاد و ولدها و مرگ و میرها اتفاق میافتد. این رویه تا ایجاد نسلهای آینده ادامه مییابد. بدین ترتیب هر نسل تابعی از نسل ما قبل خود خواهد بود.
—
در این سایت ها حالت هایی که ممکن است رخ دهد شبیه سازی شده است :
https://lazyslug.com/lifeview/
https://farzadex-eth.github.io/js-game-of-life/
بازی زندگی کانوی (به انگلیسی: Conway's Game of Life) یا بازی زندگی یا بهطور مختصر زندگی (Life)، یک اتوماتای سلولی است که توسط ریاضیدان انگلیسی جان هورتون کانوی در سال ۱۹۷۰ میلادی به وجود آمد. بازی زندگی مشهورترین نمونه یک اتوماتای سلولی است.
زندگی یک بازی بدون بازیکن است، بدین معنا که تکامل آن تنها وابسته به وضعیت و شرایط آغازین آن بوده و نیازی به عامل ورودی انسانی در مراحل بعد ندارد. نحوه تراکنش انسانی با بازی بدین صورت است که فرد در شروع بازی حالت ابتدایی چیدمان را به وجود میآورد و سپس چگونگی رشد و تکامل سیستم را بدون دخالت خود مشاهده میکند.
دنیای بازی زندگی از یک جدول نامتناهی دو بعدی با بردارهای متعامد ساخته شدهاست که شامل سلولهای مربع شکل است. هر سلول میتواند یکی از دو حالت زنده یا مرده را داشته باشد. هر سلول با هشت سلول همسایه و همجوار خود به صورت افقی، عمودی و مورب، در تراکنش است. در هر مرحله زمانی از بازی، تحولات زیر اتفاق میافتند:
۱. هر سلول زنده با کمتر از ۲ همسایه زنده، میمیرد. (به دلیل کمبود جمعیت)
۲. هر سلول زنده با بیش از ۳ همسایه زنده، میمیرد. (به دلیل ازدحام جمعیت)
۳. هر سلول زنده با ۲ یا ۳ همسایه زنده، زنده میماند و به نسل بعد میرود.
۴. هر سلول مرده با دقیقاً ۳ همسایه زنده، دوباره زنده میشود.
الگوی آغازین بازی به عنوان بذر سیستم به حساب میآید. اولین نسل در بازی با اعمال قوانین فوق بر تک تک سلولها به صورت همزمان ایجاد میشود و در آن زاد و ولدها و مرگ و میرها اتفاق میافتد. این رویه تا ایجاد نسلهای آینده ادامه مییابد. بدین ترتیب هر نسل تابعی از نسل ما قبل خود خواهد بود.
—
در این سایت ها حالت هایی که ممکن است رخ دهد شبیه سازی شده است :
https://lazyslug.com/lifeview/
https://farzadex-eth.github.io/js-game-of-life/
Lazyslug
LifeViewer
LifeViewer: a scriptable pattern viewer and editor used to simulate Life and a wide range of other 1D and 2D cellular automata. Author: Chris Rowett
❤8
سمفونی شماره ۹ (بتهوون)
سفارش ساختِ سمفونی از سوی «انجمن فیلارمونیک لندن» در سال ۱۸۱۷ داده شد. تصنیف این اثر بین سالهای ۱۸۲۲ و ۱۸۲۴ پایان یافت.هر قسمت از تاریخچهٔ سمفونی نهم، بیانگر بخشی از زندگی بتهوون است. سرود شادی قبل از سمفونی شماره ۱ مورد نظر وی بود و از سال ۱۷۹۳ طرحهایی برای یک منظومهٔ کُرال تهیه کرده بود. موومان اول در سال ۱۸۱۲ ساخته شد. تم اسکرتسو در سال ۱۸۱۵ تصنیف شد و به همین خاطر بتهوون سالها در فکر ساخت سمفونی نهم بدون بخش آوازی بود. بتهوون تا یک سال قبل از اتمام اثر، قصد داشت آن را با موسیقی سازی به پایان برساند، اما در سال ۱۸۲۳ هنگامی که طرحِ قطعهٔ میسا سولمنیس را آماده میکرد، تصمیم گرفت فینال سمفونی را با آواز به پایان برساند و بار دیگر سرود شادی مورد توجه وی قرار گرفت. بتهوون پس از اولین اجرا نیز قصد داشت فینال سمفونی را تغییر دهد و با موسیقی سازی به پایان برساند. یادداشتهایی که از بتهوون به جای مانده نشان میدهد که وی به طرحهای مختلفی برای ورود آواز در موومانهای دیگر پرداختهاست و نمیتوانست تصمیم بگیرد که کجا نوازندگان ارکستر را رها کند و به آواز بپردازد. وی در این مورد میگوید
《 وقتی اندیشهای در خاطرم میگذرد آن را بهصورت صدای ساز میشنوم و نه بهصورت صدای انسانها 》
افکار بتهوون با صدای ساز سازگارتر بود و ورود آواز را با تأخیر شروع میکرد. در فینال سمفونی نیز تم اصلی «سرود شادی» به ارکستر واگذار شدهاست و قبل از اینکه گروه کر «سرود شادی» را بخواند، این وظیفه را ابتدا به ارکستر دادهاست.
بتهوون تلاش و زحمت بسیاری برای ساخت تِمِ «سرود شادی» کشید و در نهایت سمفونی نهم آماده شد، اما وقتی که قصد داشت آن را به اجرا بگذارد، دو سال از سفارش کار توسط «انجمن فیلارمونیک لندن» و پرداخت مبلغ ۵۰ لیره بابت نسخهٔ دستنویس گذشته بود. بتهوون به علت فقر شدید و جبران خسارتهای مالی، تصمیم گرفت سمفونی نهم را نزد خود حفظ کند و به جای آن سمفونی دیگری برای انجمن بسازد. وی مصمم بود تا آخرین لحظهٔ عمرش تعهد خود را به انجمن به سرانجام برساند و طی نامهای تصمیم خود را به اطلاع انجمن رساند که در حال ساخت سمفونی دهم است و به جای سمفونی نهم به لندن خواهد فرستاد. اما طرحهایی که بتهوون برای سمفونی دهم تهیه کرده بود، به سرانجام نرسید و در نهایتِ فقر و تنگدستی درگذشت.
سمفونی نهم در سختترین روزهای زندگی بتهوون ساخته شد و هنگام تصنیف این اثر، قادر به شنیدن نبود و در ناشنوایی کامل بهسر میبرد.
سفارش ساختِ سمفونی از سوی «انجمن فیلارمونیک لندن» در سال ۱۸۱۷ داده شد. تصنیف این اثر بین سالهای ۱۸۲۲ و ۱۸۲۴ پایان یافت.هر قسمت از تاریخچهٔ سمفونی نهم، بیانگر بخشی از زندگی بتهوون است. سرود شادی قبل از سمفونی شماره ۱ مورد نظر وی بود و از سال ۱۷۹۳ طرحهایی برای یک منظومهٔ کُرال تهیه کرده بود. موومان اول در سال ۱۸۱۲ ساخته شد. تم اسکرتسو در سال ۱۸۱۵ تصنیف شد و به همین خاطر بتهوون سالها در فکر ساخت سمفونی نهم بدون بخش آوازی بود. بتهوون تا یک سال قبل از اتمام اثر، قصد داشت آن را با موسیقی سازی به پایان برساند، اما در سال ۱۸۲۳ هنگامی که طرحِ قطعهٔ میسا سولمنیس را آماده میکرد، تصمیم گرفت فینال سمفونی را با آواز به پایان برساند و بار دیگر سرود شادی مورد توجه وی قرار گرفت. بتهوون پس از اولین اجرا نیز قصد داشت فینال سمفونی را تغییر دهد و با موسیقی سازی به پایان برساند. یادداشتهایی که از بتهوون به جای مانده نشان میدهد که وی به طرحهای مختلفی برای ورود آواز در موومانهای دیگر پرداختهاست و نمیتوانست تصمیم بگیرد که کجا نوازندگان ارکستر را رها کند و به آواز بپردازد. وی در این مورد میگوید
《 وقتی اندیشهای در خاطرم میگذرد آن را بهصورت صدای ساز میشنوم و نه بهصورت صدای انسانها 》
افکار بتهوون با صدای ساز سازگارتر بود و ورود آواز را با تأخیر شروع میکرد. در فینال سمفونی نیز تم اصلی «سرود شادی» به ارکستر واگذار شدهاست و قبل از اینکه گروه کر «سرود شادی» را بخواند، این وظیفه را ابتدا به ارکستر دادهاست.
بتهوون تلاش و زحمت بسیاری برای ساخت تِمِ «سرود شادی» کشید و در نهایت سمفونی نهم آماده شد، اما وقتی که قصد داشت آن را به اجرا بگذارد، دو سال از سفارش کار توسط «انجمن فیلارمونیک لندن» و پرداخت مبلغ ۵۰ لیره بابت نسخهٔ دستنویس گذشته بود. بتهوون به علت فقر شدید و جبران خسارتهای مالی، تصمیم گرفت سمفونی نهم را نزد خود حفظ کند و به جای آن سمفونی دیگری برای انجمن بسازد. وی مصمم بود تا آخرین لحظهٔ عمرش تعهد خود را به انجمن به سرانجام برساند و طی نامهای تصمیم خود را به اطلاع انجمن رساند که در حال ساخت سمفونی دهم است و به جای سمفونی نهم به لندن خواهد فرستاد. اما طرحهایی که بتهوون برای سمفونی دهم تهیه کرده بود، به سرانجام نرسید و در نهایتِ فقر و تنگدستی درگذشت.
سمفونی نهم در سختترین روزهای زندگی بتهوون ساخته شد و هنگام تصنیف این اثر، قادر به شنیدن نبود و در ناشنوایی کامل بهسر میبرد.
🐳5👍3❤2💔2
Sonia Software Notes
The "three As" Computational Thinking Process : Abstraction: Problem formulation; Automation: Solution expression; Analysis: Solution execution and evaluation.
YouTube
Jeannette Wing: Computational Thinking
Vienna Gödel Lecture 2016 with Jeannette Wing, Corporate Vice President, Microsoft Research (talk starts at 11:55)
https://informatics.tuwien.ac.at/vienna-goedel-lectures/
#ViennaGoedelLecture
#TUWienInformatics
https://informatics.tuwien.ac.at/vienna-goedel-lectures/
#ViennaGoedelLecture
#TUWienInformatics
🔥3
Metal Gear Solid 2 - Predicting the Accurate Feature
https://youtu.be/jKPDaiJTX9M
https://youtu.be/jKPDaiJTX9M
YouTube
Metal Gear Solid 2 in 2001 Predicting The Accurate Future
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
❤🔥5🆒2
چند تا رفرنس برای یادگیری الگوریتم ها :
Courses :
MIT Course
Stanford University Algorithms Specialization
Books :
Grokking Algorithms - An illustrated guide for programmers and other curious people
The Algorithm Design Manual by Steven Skiena
Introduction to Algorithms Fourth Edition
Courses :
MIT Course
Stanford University Algorithms Specialization
Books :
Grokking Algorithms - An illustrated guide for programmers and other curious people
The Algorithm Design Manual by Steven Skiena
Introduction to Algorithms Fourth Edition
Coursera
Algorithms
Offered by Stanford University. Learn To Think Like A ... Enroll for free.
👍1🍓1
Forwarded from Nima Tech Talk 💻
لطفا، بیاین از خودمون شروع کنیم تا این بساط شهربازی جمع بشه
به موقعیت هایی که:
- رنج حقوقی ندارد
- شرح کار روشن و مشخص ندارد
- حقوق نا مشخص و نا معین دارد
- لیست مهارت ها با موقعیت مطابقت ندارد
رزومه نفرستید، کمک کنین تا متوجه بشن که نیرو متخصص، سرمایه است، نه برده
کسی که به نیرو متخصص نیاز داره، کارفرماست
به لیست من آیتم اضافه کن
https://www.linkedin.com/posts/nimahkh_%D9%85%D9%86-%D9%85%D9%88%D9%86%D8%AF%D9%85-%D8%A7%DA%AF%D9%87-%D9%86%DB%8C%D8%B1%D9%88%DB%8C-%DA%A9%D8%A7%D8%B1-%D8%A8%D8%A7-%D8%B3%D8%A7%D8%A8%D9%82%D9%87-%D9%85%DB%8C%D8%AE%D9%88%D8%A7%DB%8C%D9%86-%DA%86%D8%B1%D8%A7-activity-7160898793264005120-OYBq?utm_source=share&utm_medium=member_desktop
به موقعیت هایی که:
- رنج حقوقی ندارد
- شرح کار روشن و مشخص ندارد
- حقوق نا مشخص و نا معین دارد
- لیست مهارت ها با موقعیت مطابقت ندارد
رزومه نفرستید، کمک کنین تا متوجه بشن که نیرو متخصص، سرمایه است، نه برده
کسی که به نیرو متخصص نیاز داره، کارفرماست
به لیست من آیتم اضافه کن
https://www.linkedin.com/posts/nimahkh_%D9%85%D9%86-%D9%85%D9%88%D9%86%D8%AF%D9%85-%D8%A7%DA%AF%D9%87-%D9%86%DB%8C%D8%B1%D9%88%DB%8C-%DA%A9%D8%A7%D8%B1-%D8%A8%D8%A7-%D8%B3%D8%A7%D8%A8%D9%82%D9%87-%D9%85%DB%8C%D8%AE%D9%88%D8%A7%DB%8C%D9%86-%DA%86%D8%B1%D8%A7-activity-7160898793264005120-OYBq?utm_source=share&utm_medium=member_desktop
👍13🤔1
Nima Tech Talk 💻
لطفا، بیاین از خودمون شروع کنیم تا این بساط شهربازی جمع بشه به موقعیت هایی که: - رنج حقوقی ندارد - شرح کار روشن و مشخص ندارد - حقوق نا مشخص و نا معین دارد - لیست مهارت ها با موقعیت مطابقت ندارد رزومه نفرستید، کمک کنین تا متوجه بشن که نیرو متخصص، سرمایه است،…
یکی از دلایلی که باعث میشه این اتفاق بیوفته زیاد بودن نیروی کار توی یه حوزه هستش
معمولا کم شرکتی پیدا میشه که شرح وظایف یه برنامه نویس رو درستو حسابی نوشته باشه و قیمتی که برای اون کارجو تایین کرده ( منصفانه ) باشه، مخصوصا تو این تورم که تو ۱ ماه ۲۰ درصد بهش اضافه میشه و با افزایش حقوقی که مد نظر شرکت ها هست اختلاف بسیار زیادی داره
معمولا کم شرکتی پیدا میشه که شرح وظایف یه برنامه نویس رو درستو حسابی نوشته باشه و قیمتی که برای اون کارجو تایین کرده ( منصفانه ) باشه، مخصوصا تو این تورم که تو ۱ ماه ۲۰ درصد بهش اضافه میشه و با افزایش حقوقی که مد نظر شرکت ها هست اختلاف بسیار زیادی داره
👍5
Big O Complexity Chart
O(1) - Excellent/Best
O(log n) - Good
O(n) - Fair
O(n log n) - Bad
O(n^2), O(2^n) and O(n!) - Horrible/Worst
Six major types of complexities (time and space):
Constant: O(1)
Linear time: O(n)
Logarithmic time: O(n log n)
Quadratic time: O(n^2)
Exponential time: O(2^n)
Factorial time: O(n!)
#Big_O_Notation
O(1) - Excellent/Best
O(log n) - Good
O(n) - Fair
O(n log n) - Bad
O(n^2), O(2^n) and O(n!) - Horrible/Worst
Six major types of complexities (time and space):
Constant: O(1)
Linear time: O(n)
Logarithmic time: O(n log n)
Quadratic time: O(n^2)
Exponential time: O(2^n)
Factorial time: O(n!)
#Big_O_Notation
👍12💋9✍1👌1🆒1
Forwarded from DevTwitter | توییت برنامه نویسی
#بدرد
اینکه شما بعنوان یه جونیور یا میدلول بخواید به یک برنامه نویس سینیور تبدیل بشید، فقط نیاز نیست که اون فریم ورک یا زبانی رو که بلدید رو کامل یاد بگیرید.
خیلی چالش های دیگه ای دارید که اینجا میخوام راجع بهش کمی صحبت کنم
- درک پایه برنامه نویسی
قبل از اینکه شما بخواید در یک زبان یا فریم ورک توانایی های لازم رو کسب کنید نیازه که پایه های برنامه نویسیتون رو قوی کنید، درک کنید که سیستم چطور کار میکنه، تایپ ها چی هستن، مدیریت حافظه و منابع رو بفهمید
- پاس کردن پیشنیاز ها
خیلی ها به اشتباه قبل از اینکه پیش نیاز های یک ابزار یا فریم ورک رو پاس کنند سریعا توش شیرجه میزنن و همین باعث میشه که یجاها غرق بشن توی دریایی که اونو از قبل نشناختن.
شما برای اینکه بتونید از یک فریم ورک بدرستی استفاده کنید نیازه که در ابتدا برنامه نویسی و زبانی که اون فریم ورک باهاش نوشته شده و اصول رو درک کنید بعد ازش استفاده کنید.
مثلا اگر شی گراس اون فریم ورک، اصول شی گرایی رو کامل درک کنید و بعد از اون فریم ورک استفاده کنید.
- تسلط کامل به فریم ورک و زبان
اگر از زبان یا فریم ورک خاصی استفاده میکنید، خیلی منطقیه که در اولین مرحله کاملا به اون زبان یا فریم ورک و لایف سایکل و اکثر ویژگی هاش مسلط بشید.
حتی اگر نیاز شد برید کد های اون فریم رو مطالعه کنید و روش کانتریبیوت کنید.
- گسترش دانش فنی
اصولا افراد سینیور فقط یک زبان رو پیش نمیگیرن، بلکه میرن سمت قسمت های دیگه سیستم تا اون رو درک کنند و همین باعث میشه که مجبور شن زبان ها و ابزار های جدید رو یاد بگیرن و این دید بهتری توی کار بهشون میده.
- تقویت سافت اسکیل
از یه جایی به بعد مهم نیست شما چقدر از نظر فنی آدم کاملی هستید، رفتار شما با شرایط مختلف، آدم های مختلف، شرکت ها و تسک های مختلف باعث میشه شما پیشرفت یا پسرفت کنید، پس بهش خیلی اهمیت بدید.
کانکشن سازی هم که نباید فراموش بشه!
- تجربه تجربه تجربه
اینکه خیلیا میگن تجربه صرفا باعث سینیور شدن شما نمیشه تا یه حدی درسته اما بنظرم فاکتور اصلی سینیور شدن تجربه کافیه، شما هرچقدرم علمتون زیاد باشه اما عملی نشده باشه بهتون کمک نمیکنه پس باید شرایط مختلفو تجربه کنید تا بدونید با اون ها چطور رفتار کنید.
- یادگیری بی وقفه
با اینکه هر ثانیه یه ابزار جدید لانچ میشه اما زبان ها و فریم ورک هایی که ما داریم ازشون استفاده میکنیم و کانسپت های موجود اینقد گستردن که حتی اگه برسیم اون هارو نصفه نیمه یاد بگیریم از خیلیا جلو تریم، چه برسه این ابزار های جدید، پس یادگیری رو متوقف نکنید.
- استفاده از ابزار های متنوع
با بالا رفتن تجربه شما، انتظارات از شما هم بالاتر میره و باید کم کم با ابزار های مختلف مثل سیستم های مانیتورینگ، انواع دیتابیس، ابزار های نتورک و لاگ و.. دست و پنجه نرم کنید پس برید و ابزار های مربوط به حوزه خودتون رو یاد بگیرید .
- درک کانسپت های موجود
شما از یه جایی به بعد نیاز نیست بدونید یه حلقه چطور نوشته میشه، بلکه باید بفهمید که چه معماری ای برای اسکیل کردن سیستم نیازه، سیستم دیزاینتون باید چطور باشه و چه ابزار هایی مناسب کارتون هستند و دید سطح بالاتری باید داشته باشید پس اونارو هم برید دنبالشون
- منتورینگ
از یه جایی به بعد نیازه دست بقیه رو بگیرید، اینکه شما یه جونیور رو کمک کنید هیچ ایرادی نداره و خیلیم به شما کمک میکنه، هم صحبتی با آدم های فنی باعث گسترش دید شما میشه و همین بهتون کمک فراوانی میکنه.
و حتی میتونید از افراد با تجربه تر بعنوان منتور خودتون استفاده کنید.
- کد ریویو
شاید عجیب باشه ولی این هم خیلی مهمه!
شما باید از یه جایی به بعد کد هم تیمی هاتون رو ریویو کنید و فلو های CI/CD رو مدیریت کنید، پس این مفاهیم رو باید درک کنید.
- کتاب و ریسورس های فنی
از یه جایی به بعد دیگه ما نمیخوایم راجع به سینتکس یه زبان یاد بگیریم، میخوایم بدونیم افراد بزرگتر این حوزه در مواجهه با چالش هاشون توی شرکت های بزرگ رو چطور حل کردن و تجربشون چیه؟
چاره دیگه کورس ویدئویی نیست و باید بریم سمت کتابا تا نیازهامونو رفع کنیم.
@DevTwitter | <Reza/>
اینکه شما بعنوان یه جونیور یا میدلول بخواید به یک برنامه نویس سینیور تبدیل بشید، فقط نیاز نیست که اون فریم ورک یا زبانی رو که بلدید رو کامل یاد بگیرید.
خیلی چالش های دیگه ای دارید که اینجا میخوام راجع بهش کمی صحبت کنم
- درک پایه برنامه نویسی
قبل از اینکه شما بخواید در یک زبان یا فریم ورک توانایی های لازم رو کسب کنید نیازه که پایه های برنامه نویسیتون رو قوی کنید، درک کنید که سیستم چطور کار میکنه، تایپ ها چی هستن، مدیریت حافظه و منابع رو بفهمید
- پاس کردن پیشنیاز ها
خیلی ها به اشتباه قبل از اینکه پیش نیاز های یک ابزار یا فریم ورک رو پاس کنند سریعا توش شیرجه میزنن و همین باعث میشه که یجاها غرق بشن توی دریایی که اونو از قبل نشناختن.
شما برای اینکه بتونید از یک فریم ورک بدرستی استفاده کنید نیازه که در ابتدا برنامه نویسی و زبانی که اون فریم ورک باهاش نوشته شده و اصول رو درک کنید بعد ازش استفاده کنید.
مثلا اگر شی گراس اون فریم ورک، اصول شی گرایی رو کامل درک کنید و بعد از اون فریم ورک استفاده کنید.
- تسلط کامل به فریم ورک و زبان
اگر از زبان یا فریم ورک خاصی استفاده میکنید، خیلی منطقیه که در اولین مرحله کاملا به اون زبان یا فریم ورک و لایف سایکل و اکثر ویژگی هاش مسلط بشید.
حتی اگر نیاز شد برید کد های اون فریم رو مطالعه کنید و روش کانتریبیوت کنید.
- گسترش دانش فنی
اصولا افراد سینیور فقط یک زبان رو پیش نمیگیرن، بلکه میرن سمت قسمت های دیگه سیستم تا اون رو درک کنند و همین باعث میشه که مجبور شن زبان ها و ابزار های جدید رو یاد بگیرن و این دید بهتری توی کار بهشون میده.
- تقویت سافت اسکیل
از یه جایی به بعد مهم نیست شما چقدر از نظر فنی آدم کاملی هستید، رفتار شما با شرایط مختلف، آدم های مختلف، شرکت ها و تسک های مختلف باعث میشه شما پیشرفت یا پسرفت کنید، پس بهش خیلی اهمیت بدید.
کانکشن سازی هم که نباید فراموش بشه!
- تجربه تجربه تجربه
اینکه خیلیا میگن تجربه صرفا باعث سینیور شدن شما نمیشه تا یه حدی درسته اما بنظرم فاکتور اصلی سینیور شدن تجربه کافیه، شما هرچقدرم علمتون زیاد باشه اما عملی نشده باشه بهتون کمک نمیکنه پس باید شرایط مختلفو تجربه کنید تا بدونید با اون ها چطور رفتار کنید.
- یادگیری بی وقفه
با اینکه هر ثانیه یه ابزار جدید لانچ میشه اما زبان ها و فریم ورک هایی که ما داریم ازشون استفاده میکنیم و کانسپت های موجود اینقد گستردن که حتی اگه برسیم اون هارو نصفه نیمه یاد بگیریم از خیلیا جلو تریم، چه برسه این ابزار های جدید، پس یادگیری رو متوقف نکنید.
- استفاده از ابزار های متنوع
با بالا رفتن تجربه شما، انتظارات از شما هم بالاتر میره و باید کم کم با ابزار های مختلف مثل سیستم های مانیتورینگ، انواع دیتابیس، ابزار های نتورک و لاگ و.. دست و پنجه نرم کنید پس برید و ابزار های مربوط به حوزه خودتون رو یاد بگیرید .
- درک کانسپت های موجود
شما از یه جایی به بعد نیاز نیست بدونید یه حلقه چطور نوشته میشه، بلکه باید بفهمید که چه معماری ای برای اسکیل کردن سیستم نیازه، سیستم دیزاینتون باید چطور باشه و چه ابزار هایی مناسب کارتون هستند و دید سطح بالاتری باید داشته باشید پس اونارو هم برید دنبالشون
- منتورینگ
از یه جایی به بعد نیازه دست بقیه رو بگیرید، اینکه شما یه جونیور رو کمک کنید هیچ ایرادی نداره و خیلیم به شما کمک میکنه، هم صحبتی با آدم های فنی باعث گسترش دید شما میشه و همین بهتون کمک فراوانی میکنه.
و حتی میتونید از افراد با تجربه تر بعنوان منتور خودتون استفاده کنید.
- کد ریویو
شاید عجیب باشه ولی این هم خیلی مهمه!
شما باید از یه جایی به بعد کد هم تیمی هاتون رو ریویو کنید و فلو های CI/CD رو مدیریت کنید، پس این مفاهیم رو باید درک کنید.
- کتاب و ریسورس های فنی
از یه جایی به بعد دیگه ما نمیخوایم راجع به سینتکس یه زبان یاد بگیریم، میخوایم بدونیم افراد بزرگتر این حوزه در مواجهه با چالش هاشون توی شرکت های بزرگ رو چطور حل کردن و تجربشون چیه؟
چاره دیگه کورس ویدئویی نیست و باید بریم سمت کتابا تا نیازهامونو رفع کنیم.
@DevTwitter | <Reza/>
👍10👎2👌2⚡1