Согласен что статей много, но не согласен что не надо писать - в каждой статье что-нибудь да найдётся новенькое. Да хотя бы в комментариях. Вот например - упомянули граф зависимостей, но в комментах добавили что он бесполезен. Хотя в других статьях авторы, где этот граф упоминали, не было таких комментариев.
Поддерживаю. В Java так в enum можно добавлять с запятой в конце. Удобно когда новые значения добавляешь - только плюс одна строчка в диффе. И когда удалить хочешь - тоже только её удаляешь. Я во всех enum стараюсь её использовать.
Ну тут я не согласен - не нравится монобогдан - заблокируй и дело с концом. Он же только один пишет про старые телефоны. А проблема сгенерированных статей - их пишет куча разных людей, их фиг всех заблокируешь.
Но, во-первых, недовольные чаще пишут (так как если всё хорошо, то зачем писать?!), во-вторых - так у вас хоть будет разносторонние мнение :-)
Мне вообще ваша статья понравилась (в основном я их минусю :-) ). Особенно фишка про процедурные цели. Я к этому несколько лет назад пришёл, при изучении языков. Те раньше меня изучение языков (английский, немецкий) как-то демотивало, так как по сути это бесконечный процесс. А тут где-то прочитал (или сам дошёл) что типа просто трать в день сколько то минут и всё. В итоге так несколько книг прочитал, несколько тысяч слов выучил, несколько курсов закончил. И получилось что в моменте до конца далеко - ещё много надо читать, много слов учить и т.п. И это демотивировало - типа, блин, никогда не закончится! Но если поставить цель по другому - трать по 15-30 минут в день. То как-то в итоге через пол года уже есть измеримый прогресс - книги прочитаны, в reword слова выучены, в Babbel курсы пройдены.
Плюс статье поставил, но так делать не надо - в java мире есть несколько template engine. Пока самый лучший из них https://github.com/opensagres/xdocreport . он поддерживает разные template engine внутри - velocity и free marker. Может продьюсить разные форматы помимо docx - odf, pdf (вроде что-то ещё).
Ещё есть https://github.com/thombergs/docx-stamper . Но я бы его не рекомендовал - он хоть и кажется легковесным но внутри spring идёт, плюс он плохо поддерживается (долго релизов не было), и на нём не всё можно сделать.
У меня так девелопер делал свой template engine, с кучей кода на java. В итоге переписал на xdocreport - осталось буквально 5 строк.
У меня давно подобная история была - компания после нескольких собеседований прислала письмо с офером. Ну и я на радостях всем начал рассказывать что всё, завтра с утра напишу заявление (дело было лет 15 назад - я тогда был молод и горяч :-) ). А через час приходит другое письмо - мол, подождите, нам надо подумать. Ну в итоге не было офера в ту компанию.
P.S. Кстати, тогда тоже из Сбера офер прислали. Но он был какой-то мутный - договорились на одну сумму, а прислали офер на сумму в два раза меньше, но куча каких-то премий - месячная, квартальная, полугодовая, годовая. И типа если все эти премии за год сложить с зарплатой и разделить на 12 то будет даже больше чем сумма на которую договаривались. Но в тот момент я уже имел опыт работы в фирмах, которые с зп как-то мутят. Плюс со старшими товарищами пообщался. В итоге отказался. Ушёл туда где прям копейка в копейку платили ту сумму, на которую договорились.
Вот да - например в стороннем клиенте Dropbox для Android, Dropsync, это пункт "Исключать скрытые файлы". Я это для Obsidian использую - он папку .obsidian (с точкой в начале) создаёт - и Dropsync её не выгружает. В Windows приходится PowerShell запускать, что бы добавить NTFS аттрибут. Вообще конечно ппц неочевидно.
Тоже обратил на это внимание - в статье описывается роль не тимлида, а какого-то "козла отпущения" - ты ничего не имеешь, но с тебя все требуют. Я сейчас подобную роль занимаю - людей сам набираю, сроки сам ставлю. Нравится это тем что в итоге возможностей стало больше - ты можешь сделать не только одну фичу, как девелопер, а полноценный продукт (силами других девелоперов, конечно :-) ). Ну или просто распараллелить себя - я знаю как делать, ставлю чёткие задачи, и дальше трекаю. И так может несколько больших фичей разрабатываться. Один я может одну фичу и быстрее бы сделал, но так сразу несколько фичей делается.
Поставил плюс, но со статьёй не очень согласен. Так как видел такой подход как у вас, и видел более простой - основанный на методе assertEquals. Мне он показался более универсальным - чтобы выполнить все проверки, достаточно только одного метода. Можно его несколькими расширить, типа assertNull/notNull/true/false, но всё равно внутри это будет тот же assertEquals. В вашем подходе для каждого атрибута нужно писать свою обёртку. А когда таких классов на проекте десятки и они увеличиваются - по моему это очень накладно. Так что не могли бы вы написать, почему для вас этот подход лучше обычных assertEquals? Интересно узнать другое мнение. :-)
Я мимокрокодил из java бекенда. И там у нас тоже есть разные зависимости. Но самое страшное что я делал - просто разные пути к разным Java указывал при билде проекта. И этого хватало для всех проектов. Обычно даже хватало билдится на последней версии jvm, но указывать версию старше - типа jvm 17, но говорю чтобы сбилдил под 11. И это работает.
Но когда я пробовал кодить typescript с npm, у меня так просто это не вышло - оказываемся в некоторых либах прописаны shell script которые вызываются при их установке. Я хз - стандартная это практика или нет, но в мире java это даже теоретически нельзя сделать - чтобы Gradle или Maven запустил какой-то кастомный код при скачивание jar файла. Собственно эти shell script у меня под виндой в cmd и не заработали.
Не могли бы вы подробнее рассказать, в чём проблемы иметь разные версии npm и всего остального? И почему вообще эти проблемы в возникли? Мне интересно, так как на момент изобретения npm уже существовали примеры хороших систем сборки, типа maven. Вот и Rust, который сделали позже, тоже хорошо сделан, нам мой не опытный взгляд - модули, поддержка разных версий компилятора. Всё из коробки.
Забавно - была такая же ошибка в проде у нас несколько лет назад. Очень тогда удивился что есть week year. В итоге сделал check style правило что нельзя писать YYYY, что бы никто больше не использовал.
В Dropbox есть история - удалили/изменили - всё можно открыть откатить.
Ну можно валидаторы прикрутить, которые бы проверяли после десериализации. Мы так и делаем.
Согласен что статей много, но не согласен что не надо писать - в каждой статье что-нибудь да найдётся новенькое. Да хотя бы в комментариях. Вот например - упомянули граф зависимостей, но в комментах добавили что он бесполезен. Хотя в других статьях авторы, где этот граф упоминали, не было таких комментариев.
Во чувак удивится, когда ему инвайт на хабр придёт. Если у него вообще эта почта осталась.
За США не скажу, но знакомые в Сингапуре подтвердят - дёшево (около 20-30$ ) за 1Гб.
Большое спасибо за ваши статьи! Спасибо за эти расшифровки докладов (видео я бы ни за что не посмотрел)!
Поддерживаю. В Java так в enum можно добавлять с запятой в конце. Удобно когда новые значения добавляешь - только плюс одна строчка в диффе. И когда удалить хочешь - тоже только её удаляешь. Я во всех enum стараюсь её использовать.
Так а почему проект отменили? Самое главное не сказали!
Ну тут я не согласен - не нравится монобогдан - заблокируй и дело с концом. Он же только один пишет про старые телефоны. А проблема сгенерированных статей - их пишет куча разных людей, их фиг всех заблокируешь.
Тоже так подумал с первых строчек - все проблемы только из-за того что вовремя не вставили катетер :-)
Ну это интернет - тут и послать могут. :-)
Но, во-первых, недовольные чаще пишут (так как если всё хорошо, то зачем писать?!), во-вторых - так у вас хоть будет разносторонние мнение :-)
Мне вообще ваша статья понравилась (в основном я их минусю :-) ). Особенно фишка про процедурные цели. Я к этому несколько лет назад пришёл, при изучении языков. Те раньше меня изучение языков (английский, немецкий) как-то демотивало, так как по сути это бесконечный процесс. А тут где-то прочитал (или сам дошёл) что типа просто трать в день сколько то минут и всё. В итоге так несколько книг прочитал, несколько тысяч слов выучил, несколько курсов закончил. И получилось что в моменте до конца далеко - ещё много надо читать, много слов учить и т.п. И это демотивировало - типа, блин, никогда не закончится! Но если поставить цель по другому - трать по 15-30 минут в день. То как-то в итоге через пол года уже есть измеримый прогресс - книги прочитаны, в reword слова выучены, в Babbel курсы пройдены.
Подобная проблема есть при Синдроме раздражённого кишечника - болит живот, но по анализам всё хорошо. Лечат антидепрессантами.
Плюс статье поставил, но так делать не надо - в java мире есть несколько template engine. Пока самый лучший из них https://github.com/opensagres/xdocreport . он поддерживает разные template engine внутри - velocity и free marker. Может продьюсить разные форматы помимо docx - odf, pdf (вроде что-то ещё).
Ещё есть https://github.com/thombergs/docx-stamper . Но я бы его не рекомендовал - он хоть и кажется легковесным но внутри spring идёт, плюс он плохо поддерживается (долго релизов не было), и на нём не всё можно сделать.
У меня так девелопер делал свой template engine, с кучей кода на java. В итоге переписал на xdocreport - осталось буквально 5 строк.
У меня давно подобная история была - компания после нескольких собеседований прислала письмо с офером. Ну и я на радостях всем начал рассказывать что всё, завтра с утра напишу заявление (дело было лет 15 назад - я тогда был молод и горяч :-) ). А через час приходит другое письмо - мол, подождите, нам надо подумать. Ну в итоге не было офера в ту компанию.
P.S. Кстати, тогда тоже из Сбера офер прислали. Но он был какой-то мутный - договорились на одну сумму, а прислали офер на сумму в два раза меньше, но куча каких-то премий - месячная, квартальная, полугодовая, годовая. И типа если все эти премии за год сложить с зарплатой и разделить на 12 то будет даже больше чем сумма на которую договаривались. Но в тот момент я уже имел опыт работы в фирмах, которые с зп как-то мутят. Плюс со старшими товарищами пообщался. В итоге отказался. Ушёл туда где прям копейка в копейку платили ту сумму, на которую договорились.
Вот да - например в стороннем клиенте Dropbox для Android, Dropsync, это пункт "Исключать скрытые файлы". Я это для Obsidian использую - он папку .obsidian (с точкой в начале) создаёт - и Dropsync её не выгружает. В Windows приходится PowerShell запускать, что бы добавить NTFS аттрибут. Вообще конечно ппц неочевидно.
А вы не пробовали делать поддержку нового формата файла? Те не нового блоко в md, а нового расширения файла.
Тоже обратил на это внимание - в статье описывается роль не тимлида, а какого-то "козла отпущения" - ты ничего не имеешь, но с тебя все требуют. Я сейчас подобную роль занимаю - людей сам набираю, сроки сам ставлю. Нравится это тем что в итоге возможностей стало больше - ты можешь сделать не только одну фичу, как девелопер, а полноценный продукт (силами других девелоперов, конечно :-) ). Ну или просто распараллелить себя - я знаю как делать, ставлю чёткие задачи, и дальше трекаю. И так может несколько больших фичей разрабатываться. Один я может одну фичу и быстрее бы сделал, но так сразу несколько фичей делается.
Поставил плюс, но со статьёй не очень согласен. Так как видел такой подход как у вас, и видел более простой - основанный на методе assertEquals. Мне он показался более универсальным - чтобы выполнить все проверки, достаточно только одного метода. Можно его несколькими расширить, типа assertNull/notNull/true/false, но всё равно внутри это будет тот же assertEquals. В вашем подходе для каждого атрибута нужно писать свою обёртку. А когда таких классов на проекте десятки и они увеличиваются - по моему это очень накладно. Так что не могли бы вы написать, почему для вас этот подход лучше обычных assertEquals? Интересно узнать другое мнение. :-)
Я мимокрокодил из java бекенда. И там у нас тоже есть разные зависимости. Но самое страшное что я делал - просто разные пути к разным Java указывал при билде проекта. И этого хватало для всех проектов. Обычно даже хватало билдится на последней версии jvm, но указывать версию старше - типа jvm 17, но говорю чтобы сбилдил под 11. И это работает.
Но когда я пробовал кодить typescript с npm, у меня так просто это не вышло - оказываемся в некоторых либах прописаны shell script которые вызываются при их установке. Я хз - стандартная это практика или нет, но в мире java это даже теоретически нельзя сделать - чтобы Gradle или Maven запустил какой-то кастомный код при скачивание jar файла. Собственно эти shell script у меня под виндой в cmd и не заработали.
Не могли бы вы подробнее рассказать, в чём проблемы иметь разные версии npm и всего остального? И почему вообще эти проблемы в возникли? Мне интересно, так как на момент изобретения npm уже существовали примеры хороших систем сборки, типа maven. Вот и Rust, который сделали позже, тоже хорошо сделан, нам мой не опытный взгляд - модули, поддержка разных версий компилятора. Всё из коробки.
Забавно - была такая же ошибка в проде у нас несколько лет назад. Очень тогда удивился что есть week year. В итоге сделал check style правило что нельзя писать YYYY, что бы никто больше не использовал.