Уже довольно давно использую на работе телегу. Все рабочие чаты кидаю в одну папку, благодаря чему нет смешивания.
Из плюсов: всегда на связи, например в случае аварий, потому что телега выключена только когда сплю; можно пофлудить с коллегами в нерабочее время; в целом удобный UX; легко добавлять коллег из других компаний в общие чаты для коммуникации.
Из минусов: дискавери чатов, приходится держать табличку со списком чатов компании для новых сотрудников; администрирование чатов, человек уволился - надо кикнуть (автоматизируется ботами); сильно конфиденциальное лучше не обсуждать и не пересылать.
В целом, если выбирать между мессенджерами для работы, то я выберу именно телегу. Мой work-life баланс не страдает.
В Java есть встроенный инструмент для создания локализаций, и первая попытка была именно с её использованием. Однако, она не удовлетворяла моим требованиям: частичная локализация, поддержка формата toml в ресурсах (доступны только properties), возможность прикрутить типизацию, разбить локализацию по доменам.
Других популярных библиотек под это дело замечено особо не было, но тут я и не потратил особо много времени на их поиск, поэтому было принято решение написать своё. Да и в целом я люблю делать велосипеды.
В любом случае, описанные в статье принципы подойдут любой реализации, своей или библиотечной.
А я как раз буквально пару недель назад начал пользоваться
Неправильно советует использовать поля и методы (публичные !) из других классов, просто генерирует рандомные имена.
С одной стороны недостаток, а с другой, подсказывает какой лучше контракт реализовать, мне даже помогло несколько раз. Не серебряная пуля, но неплохой помощник, как мне кажется.
Если мы говорим о стажёрах, то там нужно в первую очередь всё же обучить, а не нанести пользу. Приятно когда получается всё вместе, но критерии выбора задач всё-таки другие.
Про юникод ничего не скажу. Но относительно транслитерации этих стандартов вагон и маленькая тележка. Есть проект iuliia, там этих схем на любой вкус и цвет: российские, международные, от компаний, с диактрикой и без неё. Чем предложенный вариант лучше любого из описанных - загадка.
Я бы сказал что обязанности на одной и той же позиции могут отличаться и очень даже сильно в разных компаниях. Причем относится это к любому грейду: джун, мидл, синьор, лид и т.д.
Была 11ая винда на старом ноуте. После старта куда-то девалось 2,5гб оперативы, реклама вылезала, все эти ИИ функции, да и разрабатывать неудобно на ней. В итоге после покупки нового ноута полностью пересел на линукс. Проблемы свои тоже есть, но пользоваться намного приятнее.
Вот рецепт попроще: приходим к своему руководителю и спрашиваем, что нужно делать для повышения и в какие сроки. Если внятного ответа нет, то идём искать новую работу.
В нормальных компаниях переработки это зло, и сверхурочно никто не должен оставаться. Если для прохождения испытательного срока это обязательное условие - нафиг такую компанию.
Если я увижу, что сотрудник сам постоянно перерабатывает, то подумаю, что он скорее всего не справляется с обязанностями за отведённое время и скоро выгорит.
Выстраивайте отношения с наставником.
....
Не сомневайтесь в его экспертизе, не забивайте на советы, не перебивайте идиотскими шутками
Противоречие само в себе. Наставник тоже человек и не против поболтать на отвлечённые от задач темы, главное чтобы это не мешало работе.
Участвуйте во всех активностях.
Опять же, сотрудник должен выполнять работу, всё остальное только по желанию. Смотреть на прохождение испытательного срока будут по проделанной работе, а не по количеству выпитого пива с коллегами.
Во-первых, мне кажется есть противоречие в словах "Развитие открытого ПО — приоритетное направление" и создании проприетарного ПО.
Во-вторых, для меня это недостаток GitHub, но, к сожалению, у него есть большое международное сообщество. Лично у меня больше симпатии например к проекту Codeberg, который работает на opensource движке. А зачем мне вместо проприетарного GitHub выбирать проприетарный GitVerse без сообщества (а в будущем ограниченным ру-регионом) вместо больших международных площадок - вопрос открытый.
Когда нужно поменять пару полей в большой модельке, новый синтаксис более выигрышный. Но когда полей становится много или все, то он достаточно громоздкий, имхо.
Для меня with'еры для record'ов очень желательная фича. Пишу и на котлине и на джаве, в 90% случаев нужно как раз поменять одно-два поля. В котлине решается через copy, а в джаве сейчас приходится городить свои костыли вида copyWithField. Синтаксис возможно спорный, но фича точно нужна.
По крайней мере, при равном уровне интеллекта я буду смотреть на человека, который учил базу сам, потому что он явно сильнее мотивирован. На втором месте – тот, кто закончил универ, потому что в высших учебных заведениях как раз максимально разжёвывают условный «алфавит» и дают крепкую базу.
Почему самоучка мотивирование, чем человек сознательно пошедший на профильное образование, потому что ему нравится эта сферы?
А курсы... Если на курс пришел переучиваться человек из смежной сферы, то супер. А вот условные мамочки в декрете и уставшие продажники за 35, которые хотят войти в IT, скорее всего, окажутся не востребованы.
Почему на курсы нормально идти только из смежной сферы? Какая-то необоснованная дискриминация получается.
Уже довольно давно использую на работе телегу. Все рабочие чаты кидаю в одну папку, благодаря чему нет смешивания.
Из плюсов: всегда на связи, например в случае аварий, потому что телега выключена только когда сплю; можно пофлудить с коллегами в нерабочее время; в целом удобный UX; легко добавлять коллег из других компаний в общие чаты для коммуникации.
Из минусов: дискавери чатов, приходится держать табличку со списком чатов компании для новых сотрудников; администрирование чатов, человек уволился - надо кикнуть (автоматизируется ботами); сильно конфиденциальное лучше не обсуждать и не пересылать.
В целом, если выбирать между мессенджерами для работы, то я выберу именно телегу. Мой work-life баланс не страдает.
Спасибо за наводку, действительно формат выглядит достаточно хорошо. Вот только вот реализацию на Java надо будет делать самому.
Пока для моих потребностей хватает текущего решения, но если придётся расширять, сначала поэкспериментирую с fluent.
В Java есть встроенный инструмент для создания локализаций, и первая попытка была именно с её использованием. Однако, она не удовлетворяла моим требованиям: частичная локализация, поддержка формата toml в ресурсах (доступны только properties), возможность прикрутить типизацию, разбить локализацию по доменам.
Других популярных библиотек под это дело замечено особо не было, но тут я и не потратил особо много времени на их поиск, поэтому было принято решение написать своё. Да и в целом я люблю делать велосипеды.
В любом случае, описанные в статье принципы подойдут любой реализации, своей или библиотечной.
А я как раз буквально пару недель назад начал пользоваться
С одной стороны недостаток, а с другой, подсказывает какой лучше контракт реализовать, мне даже помогло несколько раз. Не серебряная пуля, но неплохой помощник, как мне кажется.
Если мы говорим о стажёрах, то там нужно в первую очередь всё же обучить, а не нанести пользу. Приятно когда получается всё вместе, но критерии выбора задач всё-таки другие.
Про юникод ничего не скажу. Но относительно транслитерации этих стандартов вагон и маленькая тележка. Есть проект iuliia, там этих схем на любой вкус и цвет: российские, международные, от компаний, с диактрикой и без неё. Чем предложенный вариант лучше любого из описанных - загадка.
Я бы сказал что обязанности на одной и той же позиции могут отличаться и очень даже сильно в разных компаниях. Причем относится это к любому грейду: джун, мидл, синьор, лид и т.д.
Я работаю в хорошем месте, поэтому мне не нужны такие бессмысленные телодвижения для роста.
Была 11ая винда на старом ноуте. После старта куда-то девалось 2,5гб оперативы, реклама вылезала, все эти ИИ функции, да и разрабатывать неудобно на ней. В итоге после покупки нового ноута полностью пересел на линукс. Проблемы свои тоже есть, но пользоваться намного приятнее.
Именно так, я всегда спрашиваю как выстроен процесс грейдирования, что нужно делать, какой минимальный срок до первого пересмотра граейда и т.д.
Вот рецепт попроще: приходим к своему руководителю и спрашиваем, что нужно делать для повышения и в какие сроки. Если внятного ответа нет, то идём искать новую работу.
Я переход не подгонял, давали по заслугам. Но не везде, где я собесился, меня оценивали аналогично.
Зарплата не была целью. Меня полностью устраивало моё место работы. В причины углубляться не хочу, но по итогу я остался в том же месте.
В нормальных компаниях переработки это зло, и сверхурочно никто не должен оставаться. Если для прохождения испытательного срока это обязательное условие - нафиг такую компанию.
Если я увижу, что сотрудник сам постоянно перерабатывает, то подумаю, что он скорее всего не справляется с обязанностями за отведённое время и скоро выгорит.
Противоречие само в себе. Наставник тоже человек и не против поболтать на отвлечённые от задач темы, главное чтобы это не мешало работе.
Опять же, сотрудник должен выполнять работу, всё остальное только по желанию. Смотреть на прохождение испытательного срока будут по проделанной работе, а не по количеству выпитого пива с коллегами.
Пост максимально вредный.
Во-первых, мне кажется есть противоречие в словах "Развитие открытого ПО — приоритетное направление" и создании проприетарного ПО.
Во-вторых, для меня это недостаток GitHub, но, к сожалению, у него есть большое международное сообщество. Лично у меня больше симпатии например к проекту Codeberg, который работает на opensource движке. А зачем мне вместо проприетарного GitHub выбирать проприетарный GitVerse без сообщества (а в будущем ограниченным ру-регионом) вместо больших международных площадок - вопрос открытый.
Для меня with'еры для record'ов очень желательная фича. Пишу и на котлине и на джаве, в 90% случаев нужно как раз поменять одно-два поля. В котлине решается через copy, а в джаве сейчас приходится городить свои костыли вида copyWithField. Синтаксис возможно спорный, но фича точно нужна.
А почему сам GitVerse не opensource тогда уж?
Почему самоучка мотивирование, чем человек сознательно пошедший на профильное образование, потому что ему нравится эта сферы?
Почему на курсы нормально идти только из смежной сферы? Какая-то необоснованная дискриминация получается.
Сейчас делаю игру в качестве пет-проекта. Для расчёта баланса нужно самостоятельно прописывать формулы, использовать статистику, аналитику.
Не согласен с тем, что углублённые знания математики нужны всем и каждому, но лично я немного жалею, что в некоторых местах халявил в универе.
Наверное архитектурно лучше вынести данные для аналитики в отдельную БД и сервис (если ресурсы есть), чтобы изменения там не влияли на основной поток.