У меня дежавю - лет 20 назад, когда я учился в школе и поехал на олимпиаду по информатике - там был такой вопрос. И тут ещё даже легче - есть управляемый язык и сразу сказали что числа в массиве. А тогда был C, Pascal и задание было простое - есть число в виде строки длинной 20 символов - нужно уметь складывать и вычитать. И всё. Мне тогда вообще в голову не пришло что эту строку можно рассматривать как массив символ, что бы использовать сложение в столбик. Только потом, после олимпиады, на разборе, рассказали.
Согласен что статей много, но не согласен что не надо писать - в каждой статье что-нибудь да найдётся новенькое. Да хотя бы в комментариях. Вот например - упомянули граф зависимостей, но в комментах добавили что он бесполезен. Хотя в других статьях авторы, где этот граф упоминали, не было таких комментариев.
Поддерживаю. В 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? Интересно узнать другое мнение. :-)
Забавно - была такая же ошибка в проде у нас несколько лет назад. Очень тогда удивился что есть week year. В итоге сделал check style правило что нельзя писать YYYY, что бы никто больше не использовал.
У меня дежавю - лет 20 назад, когда я учился в школе и поехал на олимпиаду по информатике - там был такой вопрос. И тут ещё даже легче - есть управляемый язык и сразу сказали что числа в массиве. А тогда был C, Pascal и задание было простое - есть число в виде строки длинной 20 символов - нужно уметь складывать и вычитать. И всё. Мне тогда вообще в голову не пришло что эту строку можно рассматривать как массив символ, что бы использовать сложение в столбик. Только потом, после олимпиады, на разборе, рассказали.
В 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? Интересно узнать другое мнение. :-)
Забавно - была такая же ошибка в проде у нас несколько лет назад. Очень тогда удивился что есть week year. В итоге сделал check style правило что нельзя писать YYYY, что бы никто больше не использовал.