Почему ролик стоит посмотреть — рассказывают как и почему ищут, что хотят заказчики и т.д. Зачем я это смотрел? Ну... я до сих пор считаю что понаеду в Мск в будующем... наверное
KP>Кстати, а вы видели корреляцю используемого редактора и ЗП? Вообще круть, все на Emacs!
Ничего удивительного.
если чел способен освоить emasc — это реально крутой прогер.
Такому и платят соответственно.
Меня удивляет Rider в первой пятерке.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, merge, Вы писали:
M>>pycharm по рейтам ниже визуал студии M>>на чем пишут те питонисты которые рубят 350+ ?
KP>Vim, Emacs. Очевидно же
ну это же типа нотпад++ с разными расширениями, насколько я понял.
пичарм же полноценная идеа с нормальным дебагом. т.е. там производительность явно будет выше
агенства не нужны, нет ни одной уникальной вакансии
как мусорщики бегают собирают любые предложения на рынке
и перепродают от себя
нужно быть уникальным д%%%%%% что бы не найти вакансию напрямую у работодателя
а вообще посмотрев вчера
лишний раз удивился,
унижаться на каждом собеседовании (уметь продать себя как это называют по научному)
это норма https://www.youtube.com/watch?v=8RWdfyx6BqI
Здравствуйте, LaptevVV, Вы писали:
KP>>Кстати, а вы видели корреляцю используемого редактора и ЗП? Вообще круть, все на Emacs! LVV>Ничего удивительного. LVV>если чел способен освоить emasc — это реально крутой прогер. LVV>Такому и платят соответственно.
На емаксе сидят старпёры, у которых в силу возраста зарплата уже высокая. Новички на емакс не идут и потому не портят статистику. Другими словами, между емаксом и зарплатой есть корреляция (через возраст программиста), но нет причинно-следственной связи.
Кроме того, играет роль нерепрезентативная выборка. То есть если емаксом пользуются три калеки, то среднее арифметическое по этим трем калекам может быть каким угодно.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, merge, Вы писали:
M>>пичарм же полноценная идеа с нормальным дебагом. т.е. там производительность явно будет выше
KP>Хм... я полагаю что те, "которые рубят 350+" отлично знаю что дебаг не нужен как класс
ну да, сделать продукт который кроме тебя никто не вкурит, тестить на проде фидбэком от юзеров
Здравствуйте, merge, Вы писали:
M>ну да, сделать продукт который кроме тебя никто не вкурит, тестить на проде фидбэком от юзеров
Насколько я понимаю, имеются в виду юнит-тесты и логи. Некоторые утверждают что при их наличии дебаг не нужен.
Не знаю, мне все равно как-то удобно когда по шагам можно ходить и по сторонам смотреть, но я пишу не высоконагруженные бэкэнды, а обычный пользовательский софт.
Вообще отладка нужна скорее для чего-то, что имеет пользовательский интерфейс, то есть, что можно увидеть и с чем можно как-то повзаимодействовать.
Но некоторые опять же утверждают, что за то, что имеет пользовательский интерфейс, много денег не платят.
Здравствуйте, merge, Вы писали:
M>pycharm по рейтам ниже визуал студии M>на чем пишут те питонисты которые рубят 350+ ?
VSCode тоже для Питона норм.
Я не из этих богатеньких питонистов, но сам пишу или в Фаре (под Windows), либо в QtCreator (под Линуксом). Отлаживаюсь логами. PyCharm — это слишком хорошая IDE, которая задалбывает программиста, на мой взгляд, малозначащими деталями типа правильных отступов, орфографии и т.д. У меня мозг не умеет сразу охватывать всё, поэтому я сначала пишу код, добиваюсь его работоспособности, а потом его вычищаю. PyCharm же такого не допускает, заставляя своей подсветкой и бесконечными советами делать код красивым сразу, даже если он не работоспособный. Поэтому я его использую только постфактум, когда необходима тяжёлая отладка или массовый рефакторинг.
Здравствуйте, Nuzhny, Вы писали:
N>Я не из этих богатеньких питонистов, но сам пишу или в Фаре (под Windows), либо в QtCreator (под Линуксом). Отлаживаюсь логами. PyCharm — это слишком хорошая IDE, которая задалбывает программиста, на мой взгляд, малозначащими деталями типа правильных отступов, орфографии и т.д.
О, слушай, а у меня Vim как раз и с автоформатированием, и навигацией по коду, и статическим анализом на лету (через LSP). Как выпустили NeoVim с поддержкой Lua и асинхронными вызовами (чего в классическом Vim не было и все страдали), народ массово принялся очень приличные плагины под него пилить.
Здравствуйте, kaa.python, Вы писали:
KP>О, слушай, а у меня Vim как раз и с автоформатированием, и навигацией по коду, и статическим анализом на лету (через LSP). Как выпустили NeoVim с поддержкой Lua и асинхронными вызовами (чего в классическом Vim не было и все страдали), народ массово принялся очень приличные плагины под него пилить.
M>>ну да, сделать продукт который кроме тебя никто не вкурит, тестить на проде фидбэком от юзеров
KP>А можно просто добавить нормальное логирование, а так же написать модульные и интеграционые тесты. И никакой отладчик не нужен
Сказки дядюшки Римуса.
Есть полно мест, где этого добра нет и тебе никто не даст времени его написать. Да-да, мест реально много таких.
Или есть что-то частичное (только юниты).
PS: отладка по журналам занимает от разов до порядка больше времени, как правило.
Здравствуйте, kaa.python, Вы писали:
KP>А можно просто добавить нормальное логирование, а так же написать модульные и интеграционые тесты. И никакой отладчик не нужен
Во время разработки, когда тест падает — все-таки удобнее пройтись отладчиком.
А вот когда проблемы на проде — там да, только логи.
Здравствуйте, kaa.python, Вы писали:
KP>Почему ролик стоит посмотреть — рассказывают как и почему ищут, что хотят заказчики и т.д. Зачем я это смотрел? Ну... я до сих пор считаю что понаеду в Мск в будующем... наверное
Думаешь реально? Тебе же вроде около 40 сейчас, планируешь к 50 в Москве устраиваться?
Здравствуйте, merge, Вы писали:
M>ну это же типа нотпад++ с разными расширениями, насколько я понял. M>пичарм же полноценная идеа с нормальным дебагом. т.е. там производительность явно будет выше
Отладка, как и jupyter, навигация по коду, интелисенс и т.д. в vscode уже сто лет как. В емаксе тоже, хотя про jupyter не уверен. pycharm для таких языков(js, r, julia) слишком нeповоротлив. Отладчик при наличии jupyter нужен очень редко.
Уже кое что, да. Уровень растёт.
Только на кой именно сама Мск? Перенаселённая, некомфортная, огромная, "город одного дела в день"?
Большое количество компаний вполне дружелюбно к удалёнке.
Или полу-удалёнке, если позиция не рядовая, и время от времени бывает нужно и лично присутствовать, представительности ради.
Какое-нибудь под-Мск, с плюс-минус природой и т.д., да и появляться раз в неделю, не?
Впрочем, вкусы разные, кому-то нравятся муравейники, ничего не имею против.
Здравствуйте, Ватакуси, Вы писали:
В>Сказки дядюшки Римуса. В>Есть полно мест, где этого добра нет и тебе никто не даст времени его написать. Да-да, мест реально много таких.
Ну да, бывают компании где на качество продукта насрать, главное в прод запулить.
В>Или есть что-то частичное (только юниты).
Уже довольно неплохо для разработки.
В>PS: отладка по журналам занимает от разов до порядка больше времени, как правило.
ХЗ, серьёзные ошибки только в логах и проявляются, а мелочовку тесты ловят.
Здравствуйте, Nuzhny, Вы писали:
N>PyCharm — это слишком хорошая IDE, которая задалбывает программиста, на мой взгляд, малозначащими деталями типа правильных отступов, орфографии и т.д.
Я один раз фиксил немножко в питон программе, отступы это самое главное, без них вообще не скомпилится...
Здравствуйте, Nuzhny, Вы писали:
N> Отлаживаюсь логами. PyCharm — это слишком хорошая IDE, которая задалбывает программиста, на мой взгляд, малозначащими деталями типа правильных отступов, орфографии и т.д.
Или приучает сразу писать красиво и не тратить потом время на форматирование
Здравствуйте, кубик, Вы писали:
К>Я один раз фиксил немножко в питон программе, отступы это самое главное, без них вообще не скомпилится...
Я про другие отступы. Сколько строк надо отступать между комментарием перед телом функции и самой функцией? Надо ли ставить пробел между знаком комментария и самим комментарием? Если я опечатался в теле комментария зачем мне сразу об этом говорить? Если имя переменной вытекает из предметной области, а IDE это не нравится? И т.д.
Здравствуйте, Nuzhny, Вы писали:
N>Я про другие отступы. Сколько строк надо отступать между комментарием перед телом функции и самой функцией? Надо ли ставить пробел между знаком комментария и самим комментарием? Если я опечатался в теле комментария зачем мне сразу об этом говорить? Если имя переменной вытекает из предметной области, а IDE это не нравится? И т.д.
Ты знаешь, читабельность кода если ты следуешь PEP8 сильно возрастает. Сообщать об этом может быть и не обязательно, но сделать автоформатирование на сохранении очень хорошая идея. Я себе вот такую строку добавил в понфиг и вообще забыл о форматировании всегда всё хорошо выглядит.
N>Я про другие отступы. Сколько строк надо отступать между комментарием перед телом функции и самой функцией? Надо ли ставить пробел между знаком комментария и самим комментарием? Если я опечатался в теле комментария зачем мне сразу об этом говорить? Если имя переменной вытекает из предметной области, а IDE это не нравится? И т.д.
Это же само всё форматирутся. Просто включить надо.
S>и логи при креше часто не успевают записаться на диск
Делаешь mmap'ed файл и пишешь в эту память как в циклический буфер. При нормальном выходе из приложения пишешь туда метку, что файл закрыт корректно (или обнуляешь его, например). При старте приложения проверяешь эту метку. Если ядро ОС будет работоспособно при падении приложения — данные будут записаны в файл после остановки приложения. Если же у тебя произошел креш по причине падения питания, например, то и логи тебе эти не нужны.
Накладные расходы на такой журнал — каждые 30 секунд (по умолчанию) в Linux происходит сброс "грязных" страниц в файлы. Еще, как я понимаю, после сброса этих данных на диск страницы памяти будут помечены "чистыми" и при первой записи будет PAGE FAULT с переключением в контекст ядра, чтобы пометить страницу как "грязную". Итого: скорость такого журналирования равна скорости записи в память + асинхронный сброс данных на диск раз в 30 секунд + переключение в контекст ядра для пометки каждой страницы как "грязной" (т.е. страницы нужно mmap'ить по 2M). Можно журнал сбрасывать на диск принудительно, если нужно быстрее, но опять же это будет делаться асинхронно, т.е. приложение не будет ждать.
Короче, либо используй нормальный логгер, либо напиши сам (ну, или дай студенту третьекуру такую задачу — должен справиться).
Здравствуйте, Ватакуси, Вы писали:
M>>pycharm по рейтам ниже визуал студии M>>на чем пишут те питонисты которые рубят 350+ ?
В>eclipse + pyDev В>IntelijIDEA
M>>>pycharm по рейтам ниже визуал студии M>>>на чем пишут те питонисты которые рубят 350+ ?
В>>eclipse + pyDev В>>IntelijIDEA
M>типа экономят на лицензии = больше зп?
Здравствуйте, Reset, Вы писали:
R>Накладные расходы на такой журнал — каждые 30 секунд (по умолчанию) в Linux происходит сброс "грязных" страниц в файлы. Еще, как я понимаю, после сброса этих данных на диск страницы памяти будут помечены "чистыми" и при первой записи будет PAGE FAULT с переключением в контекст ядра, чтобы пометить страницу как "грязную".
Для пометки страницы как грязной не нужен никакой фолт, ни переключение в контекст ядра — процессор делает это самостоятельно и автоматически "в железе". По крайней мере на x86, ARM64 и "каноническом" RISC-V.
То, что ты описал, относится к страницам, помеченным как COW (Copy-on-Write), этот механизм в основном используется для fork'ов.
Здравствуйте, kaa.python, Вы писали:
M>>ну да, сделать продукт который кроме тебя никто не вкурит, тестить на проде фидбэком от юзеров KP>А можно просто добавить нормальное логирование, а так же написать модульные и интеграционые тесты. И никакой отладчик не нужен
Здравствуйте, Reset, Вы писали:
S>>и логи при креше часто не успевают записаться на диск
R>Делаешь mmap'ed файл и пишешь в эту память как в циклический буфер. При нормальном выходе из приложения пишешь туда метку, что файл закрыт корректно (или обнуляешь его, например). При старте приложения проверяешь эту метку. Если ядро ОС будет работоспособно при падении приложения — данные будут записаны в файл после остановки приложения. Если же у тебя произошел креш по причине падения питания, например, то и логи тебе эти не нужны.
KP>Почему ролик стоит посмотреть — рассказывают как и почему ищут, что хотят заказчики и т.д. Зачем я это смотрел? Ну... я до сих пор считаю что понаеду в Мск в будующем... наверное
странное желание. я понял бы, если в отпуск, матрешек там на Арбате прикупить, но на ПМЖ, да еще из такой страны...
Здравствуйте, merge, Вы писали:
M>ну да, сделать продукт который кроме тебя никто не вкурит, тестить на проде фидбэком от юзеров
С отладчиком намного проще исправить какой-то баг, чем без него. Часто проще под отладчиком понять в чём проблема и потом её исправить.
Но такой подход не работает, если проблема у заказчика, где-то со специфическим окружением, вызвана ошибкой многопоточного кода.
Поэтому всё равно будут ситуации, когда отладчик не спасёт. Хорошие логи, тесты, архитектура намного важнее.
Ещё, когда пользуешься отладчиком, ты рассматриваешь отдельное дерево, но часто не видишь весь лес. Я не отговариваю от отладки, это очень мощный инструмент, но он не заменит решения всех проблем.
P.S. Как люди пользуются вимом при отладке, я не понимаю. И дело не в отладчике, а в навигации по коду.
Здравствуйте, alzt, Вы писали:
A>С отладчиком намного проще исправить какой-то баг, чем без него. Часто проще под отладчиком понять в чём проблема и потом её исправить. A>Но такой подход не работает, если проблема у заказчика, где-то со специфическим окружением, вызвана ошибкой многопоточного кода.
Это если под отладчиком хоть что-то воспроизводится.
A>Поэтому всё равно будут ситуации, когда отладчик не спасёт. Хорошие логи, тесты, архитектура намного важнее.
По мне так самое важное в отладчике это, в крайнем случае это единственное что я использовал последние годы. Тест шлёпнулся — глянул почему по быстрому.
gdb program core -ex "thread apply all bt" -ex "quit" > program.dump
A>P.S. Как люди пользуются вимом при отладке, я не понимаю. И дело не в отладчике, а в навигации по коду.
Здравствуйте, Sharov, Вы писали:
S>А кто данные запишет, приложение, которое упало?
Системный вызов write() только копирует буфер в ядро(если не используется DIRECT_IO) и помечает страницы для записи. Аналогично и с mmap() — данные всегда записывает ОС. В том числе после падения приложения, и для write(), и для mmap().
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Reset, Вы писали:
S>>и логи при креше часто не успевают записаться на диск
R>Делаешь mmap'ed файл и пишешь в эту память как в циклический буфер.
В чем выигрыш?
Можно использовать обычный write(), затем fflush() чтобы libc скинуло кеш в ядро, и, если нужно, fsync() чтобы ядро сбросило свои страницы на диск. После этого данные будут на диске и сохранятся при креше системы. В большинстве случаев этого достаточно.
При использовании mmap() просто не нужен fflush(), для гарантии записи все равно нужен msync().
R>Можно журнал сбрасывать на диск принудительно, если нужно быстрее, но опять же это будет делаться асинхронно, т.е. приложение не будет ждать.
Асинхронный fsync() хотели добавить в linux, но насколько мне известно пока это не сделано.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, kaa.python, Вы писали:
KP>Отличный город, прекрасные люди, интересная работа. Только климат говно, но не может же всё быть идеально
Над климатом работа тоже ведётся.
Здравствуйте, Пофигист, Вы писали:
П>Над климатом работа тоже ведётся.
Угу. Будет 3 месяца в году + 50 в тени, а оставшееся время будет около нуля и -50 зимой
KP>Ты знаешь, читабельность кода если ты следуешь PEP8 сильно возрастает. Сообщать об этом может быть и не обязательно, но сделать автоформатирование на сохранении очень хорошая идея.
А потом кто-то с такими настройками делает pull request в твой репозитарий, исправив одну строчку, но чтобы понять это тебе приходится отревьюить 50 файлов с исправлениями в каждой второй строчке.(
Здравствуйте, jahr, Вы писали:
KP>>Ты знаешь, читабельность кода если ты следуешь PEP8 сильно возрастает. Сообщать об этом может быть и не обязательно, но сделать автоформатирование на сохранении очень хорошая идея. J>А потом кто-то с такими настройками делает pull request в твой репозитарий, исправив одну строчку, но чтобы понять это тебе приходится отревьюить 50 файлов с исправлениями в каждой второй строчке.(
Так изменения будут в основном в пробелах или переносах, которые diff может игнорировать. Поэтому отследить это одно изменение может быть не трудно.
Здравствуйте, jahr, Вы писали:
J>А потом кто-то с такими настройками делает pull request в твой репозитарий, исправив одну строчку, но чтобы понять это тебе приходится отревьюить 50 файлов с исправлениями в каждой второй строчке.(
Я крайне против того чтобы смешивать в одном PR форматирование и изменения в логике. Но при этом я не могу придумать ни одной причине не следовать PEP8.
Здравствуйте, jahr, Вы писали:
J>А потом кто-то с такими настройками делает pull request в твой репозитарий, исправив одну строчку, но чтобы понять это тебе приходится отревьюить 50 файлов с исправлениями в каждой второй строчке.(
Специально для таких случаев в IDE есть настройка, которая позволяет автоформатировать только измененные строки.
Довольно странно в очередной раз слышать об огромных зарплатах в IT. В городе где я живу, хватает дорогих квартир в новостройках за 10млн.+ (голые стены) и ремонты потом в них за 12-16. И по словам моего друга, который десятилетиями занимается дизайном и ремонтом таких квартир ( по образованию программист, в отличие от меня) ни один IT ещё ничего у него не заказывал. Или это статьи из параллельной реальности?
S>Довольно странно в очередной раз слышать об огромных зарплатах в IT. В городе где я живу, хватает дорогих квартир в новостройках за 10млн.+ (голые стены) и ремонты потом в них за 12-16. И по словам моего друга, который десятилетиями занимается дизайном и ремонтом таких квартир ( по образованию программист, в отличие от меня) ни один IT ещё ничего у него не заказывал. Или это статьи из параллельной реальности?
Ну как бы да, свет клином не сошелся на ИТ. Владелец небольшой автомойки на оживленной трассе может имет месячный доход в 1М рублей, а у некоторых таких автомомек целая сеть. Так что даже если ты умеешь "крутить" в голове красное-черное дерево, не стоить думать, что ты повелитель вселенной.
