The Rape of Proserpina, 1622, by Gian Lorenzo Bernini (1598-1680).

https://en.wikipedia.org/wiki/The_Rape_of_Proserpina

وقتی که بحث سر لیبل ها میشه و این وسط هیچ نشانه ای از فردگرایی نیست

سمفونی شماره ۹ (بتهوون)

سفارش ساختِ سمفونی از سوی «انجمن فیلارمونیک لندن» در سال ۱۸۱۷ داده شد. تصنیف این اثر بین سال‌های ۱۸۲۲ و ۱۸۲۴ پایان یافت.هر قسمت از تاریخچهٔ سمفونی نهم، بیانگر بخشی از زندگی بتهوون است. سرود شادی قبل از سمفونی شماره ۱ مورد نظر وی بود و از سال ۱۷۹۳ طرح‌هایی برای یک منظومهٔ کُرال تهیه کرده بود. موومان اول در سال ۱۸۱۲ ساخته شد. تم اسکرتسو در سال ۱۸۱۵ تصنیف شد و به همین خاطر بتهوون سالها در فکر ساخت سمفونی نهم بدون بخش آوازی بود. بتهوون تا یک سال قبل از اتمام اثر، قصد داشت آن را با موسیقی سازی به پایان برساند، اما در سال ۱۸۲۳ هنگامی که طرحِ قطعهٔ میسا سولمنیس را آماده می‌کرد، تصمیم گرفت فینال سمفونی را با آواز به پایان برساند و بار دیگر سرود شادی مورد توجه وی قرار گرفت. بتهوون پس از اولین اجرا نیز قصد داشت فینال سمفونی را تغییر دهد و با موسیقی سازی به پایان برساند. یادداشت‌هایی که از بتهوون به جای مانده نشان می‌دهد که وی به طرح‌های مختلفی برای ورود آواز در موومان‌های دیگر پرداخته‌است و نمی‌توانست تصمیم بگیرد که کجا نوازندگان ارکستر را رها کند و به آواز بپردازد. وی در این مورد می‌گوید

《 وقتی اندیشه‌ای در خاطرم می‌گذرد آن را به‌صورت صدای ساز می‌شنوم و نه به‌صورت صدای انسانها 》

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

بتهوون تلاش و زحمت بسیاری برای ساخت تِمِ «سرود شادی» کشید و در نهایت سمفونی نهم آماده شد، اما وقتی که قصد داشت آن را به اجرا بگذارد، دو سال از سفارش کار توسط «انجمن فیلارمونیک لندن» و پرداخت مبلغ ۵۰ لیره بابت نسخهٔ دست‌نویس گذشته بود. بتهوون به علت فقر شدید و جبران خسارت‌های مالی، تصمیم گرفت سمفونی نهم را نزد خود حفظ کند و به جای آن سمفونی دیگری برای انجمن بسازد. وی مصمم بود تا آخرین لحظهٔ عمرش تعهد خود را به انجمن به سرانجام برساند و طی نامه‌ای تصمیم خود را به اطلاع انجمن رساند که در حال ساخت سمفونی دهم است و به جای سمفونی نهم به لندن خواهد فرستاد. اما طرح‌هایی که بتهوون برای سمفونی دهم تهیه کرده بود، به سرانجام نرسید و در نهایتِ فقر و تنگدستی درگذشت.
سمفونی نهم در سخت‌ترین روزهای زندگی بتهوون ساخته شد و هنگام تصنیف این اثر، قادر به شنیدن نبود و در ناشنوایی کامل به‌سر می‌برد.

The "three As" Computational Thinking Process :
Abstraction: Problem formulation;
Automation: Solution expression;
Analysis: Solution execution and evaluation.

Metal Gear Solid 2 - Predicting the Accurate Feature
https://youtu.be/jKPDaiJTX9M

دوستان من بیشتر فعالیتم توی این کانال هست :
https://tttttt.me/SoniaHaven

اگر دوست داشتید جوین بشید و دلیل پست نذاشتنم خیلی موارد زیادی هست

چند تا رفرنس برای یادگیری الگوریتم ها :
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

لطفا، بیاین از خودمون شروع کنیم تا این بساط شهربازی جمع بشه
به موقعیت هایی که:
- رنج حقوقی ندارد
- شرح کار روشن و مشخص ندارد
- حقوق نا مشخص و نا معین دارد
- لیست مهارت ها با موقعیت مطابقت ندارد
رزومه نفرستید، کمک کنین تا متوجه بشن که نیرو متخصص، سرمایه است، نه برده
کسی که به نیرو متخصص نیاز داره، کارفرماست

به لیست من آیتم اضافه کن

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

یکی از دلایلی که باعث میشه این اتفاق بیوفته زیاد بودن نیروی کار توی یه حوزه هستش

معمولا کم شرکتی پیدا میشه که شرح وظایف یه برنامه نویس رو درستو حسابی نوشته باشه و قیمتی که برای اون کارجو تایین کرده ( منصفانه ) باشه، مخصوصا تو این تورم که تو ۱ ماه ۲۰ درصد بهش اضافه میشه و با افزایش حقوقی که مد نظر شرکت ها هست اختلاف بسیار زیادی داره

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

#بدرد

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

خیلی چالش های دیگه ای دارید که اینجا میخوام راجع بهش کمی صحبت کنم

- درک پایه برنامه نویسی
قبل از اینکه شما بخواید در یک زبان یا فریم ورک توانایی های لازم رو کسب کنید نیازه که پایه های برنامه نویسیتون رو قوی کنید، درک کنید که سیستم چطور کار میکنه، تایپ ها چی هستن، مدیریت حافظه و منابع رو بفهمید


- پاس کردن پیشنیاز ها
خیلی ها به اشتباه قبل از اینکه پیش نیاز های یک ابزار یا فریم ورک رو پاس کنند سریعا توش شیرجه میزنن و همین باعث میشه که یجاها غرق بشن توی دریایی که اونو از قبل نشناختن.
شما برای اینکه بتونید از یک فریم ورک بدرستی استفاده کنید نیازه که در ابتدا برنامه نویسی و زبانی که اون فریم ورک باهاش نوشته شده و اصول رو درک کنید بعد ازش استفاده کنید.

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


- تسلط کامل به فریم ورک و زبان
اگر از زبان یا فریم ورک خاصی استفاده میکنید، خیلی منطقیه که در اولین مرحله کاملا به اون زبان یا فریم ورک و لایف سایکل و اکثر ویژگی هاش مسلط بشید.

حتی اگر نیاز شد برید کد های اون فریم رو مطالعه کنید و روش کانتریبیوت کنید.


- گسترش دانش فنی
اصولا افراد سینیور فقط یک زبان رو پیش نمیگیرن، بلکه میرن سمت قسمت های دیگه سیستم تا اون رو درک کنند و همین باعث میشه که مجبور شن زبان ها و ابزار های جدید رو یاد بگیرن و این دید بهتری توی کار بهشون میده.


- تقویت سافت اسکیل
از یه جایی به بعد مهم نیست شما چقدر از نظر فنی آدم کاملی هستید، رفتار شما با شرایط مختلف، آدم های مختلف، شرکت ها و تسک های مختلف باعث میشه شما پیشرفت یا پسرفت کنید، پس بهش خیلی اهمیت بدید.

کانکشن سازی هم که نباید فراموش بشه!


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


- یادگیری بی وقفه
با اینکه هر ثانیه یه ابزار جدید لانچ میشه اما زبان ها و فریم ورک هایی که ما داریم ازشون استفاده میکنیم و کانسپت های موجود اینقد گستردن که حتی اگه برسیم اون هارو نصفه نیمه یاد بگیریم از خیلیا جلو تریم، چه برسه این ابزار های جدید، پس یادگیری رو متوقف نکنید.


- استفاده از ابزار های متنوع
با بالا رفتن تجربه شما، انتظارات از شما هم بالاتر میره و باید کم کم با ابزار های مختلف مثل سیستم های مانیتورینگ، انواع دیتابیس، ابزار های نتورک و لاگ و.. دست و پنجه نرم کنید پس برید و ابزار های مربوط به حوزه خودتون رو یاد بگیرید .


- درک کانسپت های موجود
شما از یه جایی به بعد نیاز نیست بدونید یه حلقه چطور نوشته میشه، بلکه باید بفهمید که چه معماری ای برای اسکیل کردن سیستم نیازه، سیستم دیزاینتون باید چطور باشه و چه ابزار هایی مناسب کارتون هستند و دید سطح بالاتری باید داشته باشید پس اونارو هم برید دنبالشون


- منتورینگ
از یه جایی به بعد نیازه دست بقیه رو بگیرید، اینکه شما یه جونیور رو کمک کنید هیچ ایرادی نداره و خیلیم به شما کمک میکنه، هم صحبتی با آدم های فنی باعث گسترش دید شما میشه و همین بهتون کمک فراوانی میکنه.
و حتی میتونید از افراد با تجربه تر بعنوان منتور خودتون استفاده کنید.


- کد ریویو
شاید عجیب باشه ولی این هم خیلی مهمه!
شما باید از یه جایی به بعد کد هم تیمی هاتون رو ریویو کنید و فلو های CI/CD رو مدیریت کنید، پس این مفاهیم رو باید درک کنید.


- کتاب و ریسورس های فنی
از یه جایی به بعد دیگه ما نمیخوایم راجع به سینتکس یه زبان یاد بگیریم، میخوایم بدونیم افراد بزرگتر این حوزه در مواجهه با چالش هاشون توی شرکت های بزرگ رو چطور حل کردن و تجربشون چیه؟

چاره دیگه کورس ویدئویی نیست و باید بریم سمت کتابا تا نیازهامونو رفع کنیم.

@DevTwitter | <Reza/>