Comments 64
Тайный план изучения IT.
Он очень тайный
И очень секретный
Известен немногим
1) СЯДЬ
2) КОДЬ
В связи с широким распространением планшетов, можно удвоить эффективность процесса обучения убрав первый пункт.
И будешь как студент из анекдота:
Студент как собака... Глаза умные... А сказать ничего не может!
Кодить сможешь, а за теорию пояснить нет.
Я начинал примерно так, поставил себе практическую задачу. А уже потом начал изучать какие знания мне необходимо получить для ее реализации. То есть была конечная конкретная цель, от нее и отталкивался.
Порой удобно прочитать быстро книгу по ЯП, не изучая кажду главу досконально. А потом браться за задачу. И уже в голове будут появляться подсказки: "так, про что-то такое я читал, где там это? ага, вот оно!".
Просто порой правильно поставленный вопрос, очень сильно помогает, мне. А если так читать, то в голове много как зацепки остаётся и удаётся быстро найти в гугле, нужно. Так как уже понимаешь что искать.
З. Ы. Практические задачи, очень хорошо помогают осваивать новое.
А где же ссылка на ТГ канал?
Низачот.
IMHO сразу надо Git (как минимум сохранять свои наработки с разумными комментариями и минимальной документацией именно так) и Docker (тот же SQL движок поднять) использовать в базовых функциях.
Как и Python сразу уметь в virtual env.
Тупо приучит работать "в чистоте".
Docker (тот же SQL движок поднять)
SQL не нуждается в докере. Я бы вообще не начинал поднимать тему докера пока у человека нет "базы", и он не может поднять и настроить все руками на кофеварке без готовых докер образов.
Только после этого переходить к изучению контейнеризации с полным пониманием что это всего лишь инструмент, а не универсальное решение для всего.
Вот virtual env для Питона - это, наверное, самое первое с чего нужно начинать. В начале карьеры писала маленький pet-project на питоне. Без env, а потом уже с матюками все дропала
Что-то все с ног наголову и все в кучу. Страшно представить что в итоге получится. Это программа обучения какого учебного заведения?:)
Анки карточки и т.п.
Если речь про то, что нужно прежде чем освоить любой навык правильно "учиться - учиться", то на coursera есть курс (с субтитрами в т.ч. и на русском языке)
https://www.coursera.org/learn/learning-how-to-learn
Там с точки зрения психологии, нейрофизиологии и других дисциплин именитые рассказывают как легко осваивать материал, любой.
По статье - ссылка на материалы не помешала бы.
Бытует мнение, что в итоге доходишь до момента, где выученное запоминаешь на вечно, так, что повторять тему больше не надо.
Угу-угу. Только через пару-тройку лет, все технологии сменятся, некоторые ЯП умрут (а если не умрут, то изменятся до неузнаваемости), появятся новые, сменятся парадигмы программирования, то, что считается хорошей практикой, внезапно станет плохой и т.д. и т.п.
Отметать, нужно, например, ассемблер или внутреннее устройство ОС, которые знать не обязательно и даже вредно
Без знания устройства ОС невозможно написать ПО, которое эффективно с этой ОС взаимодействует.
Представим ситуацию, мой скрипт выполняет код в «вечном» цикле. Но при этом слушает сигналы ОС SIGINT и SIGTERM, по которым корректно завершает работу.
Если скрипт не будет слушать сигналы ОС, он будет безусловно прибит ОС, и его работа будет завершена некорректно.
PS: под словосочетаниями "скрипт выполняется", "скрипт будет прибит" я имею ввиду процесс, его выполняющий.
При тестировании обнаружите проблему
Подобный скрипт при тестировании может работать вполне себе замечательно. И даже на проде сможет работать замечательно, причём годами. И даже аварийное завершение выдержать многократно, ну просто потому, что цикл будет крутиться в холостую.
А однажды сервер пошлют на перезагрузку, он предупредит процесс сигналом SIGTERM, который тот проигнорирует, после чего ОС прибьёт скрипт, который в это время чем-то занят. Упс. У нас баг. Откуда? Да фиг знает. Никогда такого не было...
Программисты начнут добавлять всякое логирование, чтобы локализовать проблему. Но логов будет крайне мало, т.к. сценарий, приводящий к ошибке — воспроизводится редко. Сервер могут ребутнуть 100 раз, но скрипт все 100 раз будет idle. А в 101-й наконец-то выяснят, что опять вот эта операция не выполнена до конца.
А почему? Да фиг знает. Откуда скрипту знать, что процесс, который его исполняет прибили? Как залогировать такое событие?
а не быть ходячим справочником по устройству ОС или ещё чему
Я немного не о том. Изначальный тезис: «знание устройства ОС - вредно». Мой тезис — нет, полезно. А всё остальное, это всего лишь аргументация. На примере, который вполне себе может иметь место в реальной жизни.
А вы не знали что эти кейсы тоже прорабатывать надо?
Упс! Появилось слово «знали». А как же тезис: «знание устройства ОС - вредно». От себя добавлю: надо ещё прорабатывать случаи зависания скрипта и утечку памяти. Но это опять же знать надо.
Что и отразится в логах, что случилось это при перезагрузке.
Каким образом? Давайте предметно. Вот часть скрипта:
Часть скрипта
public function handle(): void
{
$pdo = DB::connection()->getPdo();
// Listen to the notifications
$pdo->exec("LISTEN my_event");
$this->info('Starting');
// Forever loop
while (true) {
$notification = $pdo->pgsqlGetNotify(PDO::FETCH_ASSOC, 10000);
if ($notification) {
$this->info('Received notification: ' . json_encode($notification, JSON_THROW_ON_ERROR));
}
}
}Задание: используя статический метод debug класса Log (Log::debug()) отобразить информацию, по которой станет понятно, что произошла перезагрузка ОС.
И уже он как-то может сигнализировать скрипту, в рамках скриптового языка (исключение выбросить?)
В случае phyton и PHP скрипт самостоятельно устанавливает обработчик сигналов, который и вызовет процесс. Если программист не знает о сигналах, он не установит обработчики.
Т.е. знание ОС и SIGTERM'ов в данном конкретном кейсе вообще никак не поможет.
Именно, что поможет. Зная эти особенности программист напишет безотказный скрипт, а не будет чесать репу: почему же всё работает, логика в скрипте верная, но иногда вот случаются казусы...
Задание: используя статический метод debug класса Log (Log::debug()) отобразить информацию, по которой станет понятно, что произошла перезагрузка ОС.
Факт перезагрузки ОС будет залоггирован в логе самой ОС, в коде скрипта дополнительно ничего логгировать не надо.
Факт перезагрузки ОС будет залоггирован в логе самой ОС, в коде скрипта дополнительно ничего логгировать не надо.
Изначальное ТЗ выглядело не так, а вот так: «с помощью логирования разобраться, почему иногда тело цикла не выполняется». О том, что падение скрипта связано с убийством процесса, разработчику неизвестно.
И Ваше утверждение идёт в разрез с тезисом «знание ОС - вредно». Здесь нужно знать, где лежат журналы ОС, да ещё в зависимости от дистрибутива. Уметь пользоваться утилитами journalctl и grep.
Понимаете, знания "где в ОС лежат логи и как их посмотреть", и "как именно ОС выбирает поток для обработки сигнала, как аллоцирует его стек-фрейм, какие даёт гарантии и ограничения для его обработчика" - это очень разные знания. Для первого даже не надо быть разработчиком, с этим справится даже "продвинутый пользователь" методом тыка и гуглением при необходимости, а чтобы хорошо знать второе, нужно долго и вдумчиво читать документацию, а иногда даже заглядывать в исходники ядра и libc. Более того, скажу страшную вещь, во многих случаях было бы лучше, если бы разработчики вообще не знали про сигналы ОС. А то даже в популярных опенсорс-проектах и в коде от матёрых синьоров нет-нет да попадаются моменты, когда кто-нибудь навесит обработчик какого-нибудь SIGINT, а потом забудет восстановить errno или засунет во внутрь обработчика какой-нибудь printf и в итоге сделает только хуже. Раньше приложение просто завершалось, а теперь в одном случае из десятка наглухо подвисает что его уже нормально не убить, только SIGTERM, или с грохотом падает в сегфолт. Лучше уж бы вообще сигналы не трогали, вот честно.
SIGи это вообще часть эмуляции POSIX систем. Нативное приложение никаких SIGов не получает.
Што? Какой ещё нафиг эмуляции? Да, это часть POSIX, но причем тут эмуляция? Под Linux, macOS, *BSD это самый что ни на есть нативный механизм взаимодействия ОС с процессом (а иногда и между процессами).
Более того, под Windows некоторые из этих сигналов (SIGINT, SIGFPE, SIGABRT) тоже есть и даже работают, как натурально через signal(), так и через какую-нибудь SetConsoleCtrlHandler
Знаю множество мидлов и сеньоров, которые не знают что такое SIGINT и SIGTERM, консольный софт и так на них реагирует, ничего специального в них вводить не нужно.
А вот игнорирование сигналов, это уже не в каждом прикладном программировании нужно
Даже не знают, откуда берутся переменные окружения? Ну ладно, уговорили. Знание ОС не нужно.
Удивитесь, но да, многие не знают откуда они берутся и как работают. При этом все знают про fork.
И я не говорю, что знание ОС не нужно, я о том, как оно на самом деле. И из-за этого страдает разработка. Появляются усложненные решения.
Иногда бывает, что решения становятся излишне сложными, когда мы применяем знания ради самих знаний, а не потому, что это необходимо. Я согласен, что прикладному программисту не требуется глубокое понимание операционных систем, как у системных разработчиков. Однако базовое знание ключевых концепций будет полезным. Это как быстрый взгляд на основы, чтобы в случае необходимости, было представление о теме. Нет необходимости «отвергать» © эти знания, потому что так написали на Habr.
Вы такие страшные вещи пишите. Мне встречаются джуны, которые про относительные и абсолютные пути не знают. Но хотят 100+ получать. :)
Я тоже хочу. Где такие оклады раздают? Про пути знаю. И про символические/жёсткие ссылки тоже.
вы сколько собесов по удаленке прошли с ценником в резюме больше 100к?
Я последний собес проходил свыше 20-ти лет назад. А почему Вы спрашиваете?
ну вы же хотите 100+к, хотеть много чего можно, вот говорите знания есть... а что мешает не только хотеть но и получать столько денег?
а что мешает не только хотеть но и получать столько денег?
Видимо, эйджизм.
ну вы же хотите
Так ведь я ещё и спрашивал «где» :) Просто интересно.
вот говорите знания есть...
Ну в своё время с нуля спроектировал, разработал и внедрил платёжную систему масштаба областного центра. Она, правда, благополучно в ковид издохла... Но ведь Киберплат и тот закрыли. Хотя у него масштаб был федеральный.
последний собес проходил свыше 20-ти лет назад.
Так в этом и проблема. Подходите по собесам, и узнаете "где такие оклады раздают".
Да понимаете, до этого как-то без собесов на работы переманивали. А сейчас кругом эйджизм, ну и ИП закрывать лениво.
без собесов на работы переманивали.
и вы меньше 100к получаете?
ну и ИП закрывать лениво.
т.е. вы сами не хотите по ТК работать?
т.е. вы сами не хотите по ТК работать?
А разве ИП не по ТК работают?
PS: Вы просто так интересуетесь? Мне кажется, у нас тут уже личная переписка началась. Может быть имеет смысл убрать её из публичного поля?
А разве ИП не по ТК работают?
ну вы приводите доводы и аргументы, я пытаюсь понять почему вы не понимаете где люди получают более 100тыр
то что вы упомянули ИП, я просто предположил что вы работаете как ИП и оказываете услуги от его имени и хотите найти какуюто работу именно как ИПшник, я вероятно ошибаюсь
если не хотите продолжать, то мне некритично, мне просто интересно почему существуют ИТшники которые застревают существенно ниже рынка и жалуются что нет работы хотя у них офигенный опыт и квалификация
Да понимаете, до этого как-то без собесов на работы переманивали
Судя по вашему искреннему удивлению "где дают оклад от 100к?", тактика "переходить на работу туда, куда переманивают без собесов" для вас оказалась, скажем так, проигрышной.
POV:
Ultimate guide: на гит уделяйте 12 дней.
Me: изучаю git c 2017 года и до сих пор не все знаю.
Подтверждаю. Я git push три года неявно осваивал, там сценариев миллион. А ведь есть ещё git pull, там вообще атас...
Не занимайтесь ерундой, занимайтесь разработкой ПО.
Согласен, перешёл бы на TFS, но даже MS перешли на Git против моей воли.
Не занимайтесь ерундой, занимайтесь разработкой ПО.
Вы не понимаете, это все часть разработки ПО. Не недооценивайте системы контроля версий в индустрии, где появились микросервисы и микрофронтенды, где есть спеки OpenAPI, OpenTracing, OpenTelemetry и прочее.
Сейчас 90% не понимают разницы между системой контроля версий и системой код ревью и путают их.
А сколько статей об этом было лет 10-15 назад...
Такое огромное количество вкатунов в электриков, сантехников, бухов, юристов, психологов, прогов, сисадминов, ремонтников всех мастей. Плюнуть некуда. А и итоге, никто толком ничего не умеет. Мошенник на мошеннике да дебилом погоняет. Бежать некуда. Биомусор нескончаемый.
Автор, размет за гайд!
Поправка: мозг нас переключает каждые несколько секунд (по разным фундаментальным исследованиям от 1,5с до 3с), по-этому практически невозможно сознательно сосредотичиться на теме в течении даже 3 минут, а соответственно в течении 1 часа - это надо быть ментальным Халком.
Вывод: разбить дневное обучение/повторение на атомарные промежутки от 3 мин (если развитие мозга не позволяет) до 10-15 мин (если развитие мозга позволяет); возвращаться к повторению (1) в этот же день не менее чем через 4 часа (вывод - надо учиться с утра, когда мозг наиболее губкой является), (2) повтор через 24 часа, (3) повтор через 36 часов, (4) повтор через 72 часа, (5) для особо заточенных повтор через 7 дней и т.д.
Самое ценное, автор!, практика 80%, причем сразу. Моторные функции механизма запоминания и как следствие создания ментального облака НЕПОСРЕДСТВЕННО связана с КОНТЕКСТНЫМ ПРИМЕНЕНИЕМ (моторикой, окружающей собстановкой, запахами, эмоциональным состоянием и т.п.), как у спортсменов - можно 1 млн часов ММА и бокса смотреть, но бить правильно научишся только после 1000 монотонных правильных повторений с наращиванием скорости и без осознания, на автомате. Знания и навыки также: должны выскакивать из подкорки на автомате в соответствующем контексте и/или по обращении к ним.
АВТОР! РЕСПЕКТ! КАПИТАЛЬНЫЙ КРАСАВА! Так держать!
Мне нравится, как в статье регулярно повторяется термин "интервальные повторения".
Основы программирования, основы алгоритмики, основы ОС, основы сетей и телекоммуникаций, основы безопасности, основы формальных языков. Все остальное по необходимости и по ситуации. Зачем еще усложнять себе жизнь.
Ультимативный Гайд По Эффективному Обучению (для влёта в IT с двух ног)