Комментарии 49
Лично мне помогает разгрузиться поход в спортзал или просто прогулка по улице.
Мне тоже, но это своеобразный отдых. Во время такой прогулки/физзарядки тело отдыхает, набирается энергии, а мозг продолжает оработать. Поскольку рядом нет компьютера, то и нет возможности сразу же опробовать пришедшие в голову решения, которые порой могут быть и ошибочными. А вот хорошо поверьтет их в голове очень даже получается, порой приходят неожиданные решения и намного проще, чем если бы сидел за машиной. И много плюх можно вычистить во время таких прогулок.
Отдыхайте творчески.
Думать на отдыхе о работе??
Можно ведь и бегать. Тогда вообще сложно думать о чём бы то не было, да и не хочется. Ну, либо просто другую тяжёлую физ. нагрузку
Можно и еужно и бегать!
огда вообще сложно думать о чём бы то не было, да и не хочется.
Старанно. Можно бегать и трусцой!
Действительно тяжелую нагрузку долго не выдержишь. Обычный бег "для здоровья" не должен быть тяжелым, при этом он довольно монотонен. Я вполне решал во время бега и свои рабочие задачи и олимпиадные задачки сына. Чтобы отвлечься нужно занять мозги - чтение, просмотр чего-либо... из физнагрузок - либо что-то игровое, либо просто связанное со сложной координацией движений.
Вспоминается демотиватор
Расскажи им, как ты устал сегодня в офисе...
Спасибо, за статью!
Подскажите пожалуйста, как вы нашли работу? Я уже месяц ищу работу, но пока тихо.
Хорошие советы, не открытие Америки, реальный опыт. Лойс
С каких пор люди, только недавно устроившиеся на свою первую работу, имеют моральное право раздавать свои советы направо и налево? Хабр когда-то был местом, где делятся опытом лучшие из лучших. Профессионалы. Указывают на неочевидные вещи. Рассказывают об эпичных фейлах и головокружительных успехах. Предотвращают ошибки. А что я вижу теперь? "Почитай книжку про Git и сделай рефакторинг". Серьезно?! Считаю, модераторам портала следует немного построже работать со статьями, содержащими избитые истины. Нет никакого интереса читать эту воду в ленте.
Лучшие из лучших - это вы загнули, но действительно классные статьи бывали частенько. Сейчас они тоже есть - очень редко, статья, про которую можно сказать "хабратортно". И все понятно - писать долго статью чтобы она утонула в потоке хреновых переводов на главной и мусорных статей - занятие не благодарное. Поэтому вот, как есть, увы.
Автор делится своим джуновским опытом с другими джунами. Или советы всем должна раздавать только абстрактная "элита", которая уже давно не является джунами и даёт советы, которые новичок любо не поймет, либо ему это пока не нужно?
Джуны имеют полное право раздавать советы тем, кто ещё даже не Джун. :)
У кого опыт 20+ немного о другом думают. И дают советы тем, у кого опыт 10+. Образно конечно.
А разве по заголовку статьи не понятно, о чем пойдет речь? Кому интересно и познавательно, тот прочтет. Кому нет - пропустит. Или хабр только для «элиты»?
А с каких пор люди, только недавно устроившиеся на свою первую работу, НЕ имеют моральное право раздавать свои советы? Браво! Вот действительно тот хабр, который все заслуживают. Алло! Какая еще илита? Вот поэтому хабр и скатывается в безду, потому что оторвано от комьюнити и реальности, где тусуются в своем каком-то мирке.
Такое уже давно: хорошие статьи — редкость, достойные профи перестали писать и делиться опытом. Пропаганду удалять уже нельзя — покушение на свободу слова. А раз дичь стала нормой, то и остальные компании стали тоже писать всякую ахинею.
Я буду продолжать продвигать идею "Судов присяжных для Хабра".
Любой человек, при наличии какого-то определенного порога кармы, который увидил такую гофноту в ленте может попросить собрать суд присяжных. При этом, он должен без эмоций описать что не так со статьёй.
Из всех авторов, которые активны и меют больше 100 кармы, случайным образом выбирается 12 авторов. Им представляется обвинение на статью и то, почему она не Торт.
У присяжных есть 2 дня на то, чтобы каждый независимо вынес своё решение и высказал своё мнение. При этом, автор комментария не имеет права говорить, что статья не торт. Ему надо написать, как эту статью исправить, чтобы она была тортом. (В данном случае, например, можно сказать следующее - представленный опыт сликом однобок и узок. У автора нет достаточного опыта для написания этой статьи. Но если автор пойдёт и опросит своих друзей-программистов, то добавив их опыт, он сможет составить хорошую статью)
Если большинство сказало, что статья - кака, то статья отправляется в черновики, со всеми комментариями по улучшению статьи.
Статью можно будет переопубликовать через неделю с поправками. При этом, присяжные перепроверяют качество, и если оно прошло, то всё хоршо. А если нет, то статья навеки отправляется в черновики.
При этом, модераторам Хабра не надо будет пачкать свои руки в том, чтобы пытаться снять статью. У них есть свои правила, и я понимаю, что некоторые из них это читают с кислой миной и мыслью "Забанил бы". Но у них нет возможности и права этого сделать.
А если мы создаём коллегиальный орган, где условием работы будет необходимость развёрнутых ответов по поводу того, как это исправить, то тогда и модераторы тут ни при чём.
А то висят тут, статьи про астрологию, написаные ChatGPT, и всем от этого становится плохо.
Разве польза Хабра не в обмене опытом начинающих разработчиков в том числе? Вроде заголовок есть с конкретной темой и если не нравится, то не читай...
Если раньше можно было спокойно использовать Dockerfile c образом alpine и было ОК, то теперь надо искать эффективные и надёжные альтернативы (например, python-slim-buster).
Ну да, расскажите эксплуатации с высоты своего опыта, какой образ лучше использовать, как деплоить, про настройку Куба расскажите...
Оффтоп. В чем преимущество делать бекенд на питоне?
В том, что это коммерчески востребовано
В том же, в чём преимущество использования питона в принципе. Он создавался как язык, на котором можно было бы разрабатывать быстро. Т.е. удобный синтаксис, много сахара, декораторы, слайсинг и т.п. А также интерпретируемость, позволяющая не ждать пересборки всего проекта при отладке, если ты изменил одну строку.
Почему в таком случае его сейчас не выбирают все подряд - программы, написанные на нём работают медленнее, чем на Java или .NET, отчасти засчёт той же интерпретируемости, поскольку компиляторы способны выдавать очень сильные оптимизации, т.к. знают обо всём твоём коде сразу.
То есть питон выгоден, если надо быстро и в сжатые сроки построить систему и отдать заказчику, но если в системе много вычислений, которые должны работать быстро, то другие языки предпочтительнее.
Btw, могу ошибаться, ибо сам являюсь .NET разработчиком, но в своё время был в восторге от питоновских декораторов, иногда их не хватает
Пошёл прочитал, про декораторы.
Декоратор — это функция, которая позволяет обернуть другую функцию для расширения её функциональности без непосредственного изменения её кода.
Тот факт, что всё является объектами, открывает перед нами множество возможностей. Мы можем сохранять функции в переменные, передавать их в качестве аргументов и возвращать из других функций.
В .Net делегаты есть. Или я что-то не так понял?
Делегаты про передачу функции в качестве параметра. Да, можно сделать подобие вызова функции с декоратором с помощью делегатов, но это будет вызов вида Декоратор(Функция, [параметры функции]), вместо обычного Функция([параметры функции]).
Представим, что мы пишем библиотеку. Разработчик, её использующий, будет видеть только сигнатуры функций. Если мы в питоне навесим на неё декоратор, он будет использован при обычном вызове функции. А в примере с делегатом этот разработчик может не знать о декораторе и не вызвать его.
Да, можно сделать функцию 1 приватной, затем сделать публичную функцию 2, которая будет вызывать функцию 1 с декоратором, но тут возникает проблема: если у нас есть один декоратор, который мы навешиваем на несколько разных функций, то для каждой придётся писать такой дубликат.
В общем, декоратор - удобный синтаксический сахар. При желании на чём угодно можно написать что угодно, вопрос лишь в том, сколько времени это займёт. В питоне навесить декоратор - написать одно слово с @ перед функцией. В примере выше, хоть и немного, но написать нужно больше. А теперь помножим это на количество таких ситуаций, и ещё раз помножим на тот факт, что декоратор - это лишь один из примеров, а подобных сладостей в питоне много. Мне например, ещё очень нравится слайсинг. Вот из всего этого сахара и складываются меньшие затраты времени на разработку.
И, опять же, это лишь общая идея того, для чего вообще создавался питон, я не ручаюсь, что это так работает в реальности, ибо в .NET тоже хватает сахара, по сравнению с той же Java. Я её как-то попробовал, и обплевался от отсутствия даже такой банальной вещи, как Свойства классов. Но это лишь моё мнение, кому-то и без них норм, да и Легаси кому-то надо поддерживать
Я несколько лет пишу и на Java, и на C#. Так вот я так и не смог привыкнуть к Java. Слишком много чего нет из того, что есть в C#. Тот же LINQ, например, и много чего еще.
Если Вы используете JVM, то можно писать код на Kotlin. Результатом будет тот же байт-код, а проблема с неудачными конструкциями в Java исчезнет сама собой.
Более того, один и тот же проект может иметь код как на Java, так и на Kotlin (то есть файлы могут соседствовать).
А в Java вроде уже относительно давно есть некие стримы, или это тоже не то?
Спасибо! Вроде понял разницу. А если
Разработчик, её использующий, будет видеть только сигнатуры функций. Если мы в питоне навесим на неё декоратор, он будет использован при обычном вызове функции.
когда я потребитель такой функции я вижу, что на ней декоратор или это от меня скрыто?
Про слайсы - в .Net есть Span<T>, правда без параметра step
когда я потребитель такой функции я вижу, что на ней декоратор или это от меня скрыто?
Тут лучше спросить питониста, но я предположу, что скрыто. Как и любая другая деталь реализации в целях инкапсуляции.
Про слайсы - в .Net есть Span<T>, правда без параметра step
Так step - это самое сладкое!
Я имел ввиду немного другое. Если я, допустим, вызываю делегат в C# там тоже все скрыто. Но, в основном, я могу установить какой конкретно код вызывается, проследив, где делегат был создан. В python я пойму, что функция обернута в декоратор в процессе разработки, или я буду ожидать одного, а в ответ получить могу другое?
Вот здесь я вас не очень понял.
Если это код ваш или вашей команды, и находится в рамках одного проекта/решения, то вам, вероятно, даже IDE подскажет.
Если это код закрытой библиотеки, то всё, что у вас есть - это документация. И тогда всё зависит от неё.
Ожидать одно, получить другое - в целом всё зависит от конкретной ситуации, от того, как хорошо описана функция. Не от наличия декоратора. Да и сами декораторы нужны лишь для пред- и пост-обработки. Не думаю, что кто-то будет писать их для того, чтобы сбить вас с толку.
Шутка смешная, ситуация страшная)
Python же до 10 раз медленнее того же PHP.
Хочу еще некоторые дополнения внести про отдых и разгрузку.
Поход в спортзал и прогулка, все таки может сопровождаться мыслями о работе, по крайней мере у меня. Если у кого-то точно также, то я советую вам применить немного другой подход.
Мне кажется что разгружаться стоит как физически так и творчески. Я после рабочего дня (или в перерывах) играю на гитаре, и это максимально помогает мне. Я отвлекаюсь от своих задач, компьютера и получаю от этого удовольствие. Иногда я рисую, или даже пою и это тоже полностью помогает отвлечься от задач. Даже элементарно приготовить еду включив на фоне сериал очень поможет вам забыться на несколько часов о работе. И каждый день, я гуляю (не смотря на погоду). Прогулка нужна лично для меня, по той причине что я хочу чтобы мои глаза отдохнули, выходя на улицу я смотрю вдаль, и таким образом берегу свои глаза.
Как сказал Роберт Мартин (Дядя Боб) в своей книге «Идеальный программист. Как стать профессионалом разработки ПО»
Не пишите код, когда вы устали. Преданность делу и профессионализм проявляются в дисциплине, а не в продолжительности работы. Обязательно следите за сном, здоровьем и образом жизни, чтобы вы могли ежедневно посвятить работе восемь хороших часов.
Поход в спортзал и прогулка, все таки может сопровождаться мыслями о работе
Если вы ходите в спортзал чтобы заниматься единоборствами, игрой в командные виды спорта или заниматься видами спорта типа гимнастики, у вас мыслей о работе особо возникать не будет. Если просто потягать железо, то да.
Гитара тоже хорошо, но раздражает людей (не все любят когда гитарист сидит дома после работы и гоняет гаммы по кругу часами) и не дает физ нагрузки важной для людей, которые по 8+ часов в день проводят в сидячем положении за монитором.
Цитата из приведенной Вами статьи(https://habr.com/ru/companies/oleg-bunin/articles/488010/):
Сначала техническая часть, потом — DDD. Скульптор, который высекает статую из камня не читает мануал о том, как держать молоток и долото — он уже знает, как ими работать. Чтобы привнести DDD в ваш проект, освойте техническую часть: выучите до конца Django, прочитайте туториал и перестаньте спорить, что брать — PostgreSQL или MongoDB.
Т.е. все-таки это не для Junior уровня. DDD - скорее про архитектуру кода. Если нет знаний и опыта на множестве инструментов то и DDD банально не сможете использовать.
Сдается мне что бизнес решил сэкономить на кадрах.
Пример личного опыта новичкам интересен.
Только смотрю я на всё это... и подсознательно чувствую, что что-то неправильно во всём этом, какой-то тупик. Бесконечное изучение инструментов, инструментов, инструментов... бесконечное перекладывание их с места на место, замена одних другими... В общем переливание из пустого в порожнее. Причем такого рода знания очень быстро устаревают, приходится постоянно крутить педали, чтобы не упасть. Т.е. такие знания, в отличие от фундаментальных, сами по себе малоценны, а ценность обретает лишь поддержание этих знаний в актуальном состоянии. Потом, если устаканится как-то, то работа идет по жестким шаблонам, с фанатичным соблюдением отступов и прочих фентифлюшек. Творческий подход, новизна, оригинальные идеи - всё это улетучивается. Получается, это уже даже не ремесло, а чистый конвейер. Бизнесу нравится. Наверно, это и есть путь к выгоранию...
Извините, это просто сетование ни о чём...
PS
Когда я делаю какой-нибудь личный проект, там процесс совсем иной: большую часть разработки я веду, прогуливаясь по парку, читая смежную литературу. Это занимает где то 80% времени разработки. И только остальные 20% - набор кода, отадка и пр.
Когда я делаю какой-нибудь личный проект, там процесс совсем иной: большую часть разработки я веду, прогуливаясь по парку, читая смежную литературу. Это занимает где то 80% времени разработки. И только остальные 20% - набор кода, отадка и пр.
Советую углубиться в философию марксизма в таком случае. Там объясняется это.
Если вкратце и по сути:
Компании интересны только 20% - их и будут оплачивать ибо они с них могут поиметь доход. А вот все остальное - пожалуйста сами себе оплачивайте.
Всё правильно написано, но только надо делать скидку, что каждый разработчик варится в своей среде. Нахрен тебе докеры, нгинксы и ансиблы, если ты разработчик для микроконтроллеров, например.
Тут скорее совет в духе: узнавай, какими инструментами пользуются в твоей области: а может ты разработчик на 1С, например. Или мобильный разработчик. Или разработчик нативных GUI-приложений под Linux. Или разработчик драйверов. Да мало ли разных сфер. И в каждой из них свои инструменты и свои подходы и никто не знает, что из этого будет живо через 5 лет, а что подохнет в море "миллиардов новомодных фреймворков".
Лучший совет уже прозвучал когда-то от Стива Джобса: stay foolish, stay hungry.
автор слушает славу кпсс?
я, как человек, который только начал путь в it, возьму твои советы на вооружение и чуть позже буду рассматривать данные ресурсы подробнее. спасибо.
Что я понял на первой работе программистом / Мои советы Junior-разработчикам