Но, во-первых, недовольные чаще пишут (так как если всё хорошо, то зачем писать?!), во-вторых - так у вас хоть будет разносторонние мнение :-)
Мне вообще ваша статья понравилась (в основном я их минусю :-) ). Особенно фишка про процедурные цели. Я к этому несколько лет назад пришёл, при изучении языков. Те раньше меня изучение языков (английский, немецкий) как-то демотивало, так как по сути это бесконечный процесс. А тут где-то прочитал (или сам дошёл) что типа просто трать в день сколько то минут и всё. В итоге так несколько книг прочитал, несколько тысяч слов выучил, несколько курсов закончил. И получилось что в моменте до конца далеко - ещё много надо читать, много слов учить и т.п. И это демотивировало - типа, блин, никогда не закончится! Но если поставить цель по другому - трать по 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, что бы никто больше не использовал.
Почему в России многие до сих пор не любят немцев и называют их фашистами?
Ну по крайней мере после войны официальная политика заключалась как раз в том что не называть всех фашистами. Никакой коллективной вины. А вы тут это оправдываете. Ну те человеческие чувства понятны, но мы тут не малые дети и можем контролировать эмоции.
P.S. У меня родственники по обе стороны. Бомбят друг друга. Но при этом как-то общаемся.
если ввести строку поиска «mad», то она не будет соответствовать «madzag» (что означает «верёвка»), потому что «dz» в «madzag» — это отдельная буква, а не «d», за которой следует «z»
Если кто-то решил перепроверить - нет, тут две отдельные буквы. Но в таблицах - да, один символ. :-)
Это да, самое не выгодное что делать в Германии - работать. У нас сейчас так - оба работают, но в итоге не сильно больше если бы один работал. Сравнивали с разными людьми у которых только один работает.
Хм. Вот то что вы сейчас описали - очень напоминает JIT компиляцию в Java. Сначала интерпретируем код. Медленно, но зато собираем статистику. А потом компилируем. Мне кажется VM языки с JIT отлично бы прижились здесь.
Ну я тут не то что бы полностью согласен с вами, но вот недавно сам пересматривал свои гигабайты скаченных статей про Java - jsp, servlets, Application Servers, про Delphi. И понимаю что хоть они и навевают радостные ностальгический воспоминания, но они практически полностью бесполезны сейчас. Так что может в качестве временного решения - сохранить оффлайн, чтобы потом почитать где-нибудь в дороге без интернета, - это и норм, сохранить к себе на диск. Но копить эту инфу годами и наполнять её для дальнейшего использования - конкретно для меня получилось проще это найти в сети.
А вы не пробовали сжимать json? У нас похожая проблема была, и в итоге просто добавили gzip. Определённо это не идеальное решение - размер всё равно больше чем avro/protobuf, зато со схемой проще - pojo файл конечно нужен, если мы хотим это сообщение использовать, но всегда можно на raw сообщение посмотреть, что бы понять что там вообще есть. А в хедере полное имя класса передаётся и по нему можно десериализовать.
А что бы универсально работало - gzip/string - есть magic number у gzip. Т.е. в топике просто байты, а на стороне клиента уже по первым 3 байтам понимается - это gzip или string.
Мы разные решения перепробовали и остановились на этом как наиболее универсальное - json сейчас все поддерживают - ui, backend, и человеком читается :-)
А почему markdown выбрали, а не asciidoc? Меня в md смущает собственно отсутствие md - каждый пилит собственный формат на основе него - GitHub, Obsidian, BitBucket ну и вы.
Ну это интернет - тут и послать могут. :-)
Но, во-первых, недовольные чаще пишут (так как если всё хорошо, то зачем писать?!), во-вторых - так у вас хоть будет разносторонние мнение :-)
Мне вообще ваша статья понравилась (в основном я их минусю :-) ). Особенно фишка про процедурные цели. Я к этому несколько лет назад пришёл, при изучении языков. Те раньше меня изучение языков (английский, немецкий) как-то демотивало, так как по сути это бесконечный процесс. А тут где-то прочитал (или сам дошёл) что типа просто трать в день сколько то минут и всё. В итоге так несколько книг прочитал, несколько тысяч слов выучил, несколько курсов закончил. И получилось что в моменте до конца далеко - ещё много надо читать, много слов учить и т.п. И это демотивировало - типа, блин, никогда не закончится! Но если поставить цель по другому - трать по 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, что бы никто больше не использовал.
Ну по крайней мере после войны официальная политика заключалась как раз в том что не называть всех фашистами. Никакой коллективной вины. А вы тут это оправдываете. Ну те человеческие чувства понятны, но мы тут не малые дети и можем контролировать эмоции.
P.S. У меня родственники по обе стороны. Бомбят друг друга. Но при этом как-то общаемся.
Если кто-то решил перепроверить - нет, тут две отдельные буквы. Но в таблицах - да, один символ. :-)
Это да, самое не выгодное что делать в Германии - работать. У нас сейчас так - оба работают, но в итоге не сильно больше если бы один работал. Сравнивали с разными людьми у которых только один работает.
Наверное многие теперь заграницей и знают как там жить :-)
Хм. Вот то что вы сейчас описали - очень напоминает JIT компиляцию в Java. Сначала интерпретируем код. Медленно, но зато собираем статистику. А потом компилируем. Мне кажется VM языки с JIT отлично бы прижились здесь.
Живу в Германии. Полностью согласен со статьёй.
Отличная статья, спасибо!
Раз у вас такой большой и обширный опыт в AI, не могли бы посоветовать обзорную статью про эти платы - о том как их применять на практике?
Ваша статья немного это затрагивает, но мне хотелось бы больше почитать о практическом применение. Но для дилетантов :-)
Kiwi. Но он закрытый. Это если вам прям исходники нужны. Но зато он extensions от Chrome поддерживает.
Ну я тут не то что бы полностью согласен с вами, но вот недавно сам пересматривал свои гигабайты скаченных статей про Java - jsp, servlets, Application Servers, про Delphi. И понимаю что хоть они и навевают радостные ностальгический воспоминания, но они практически полностью бесполезны сейчас. Так что может в качестве временного решения - сохранить оффлайн, чтобы потом почитать где-нибудь в дороге без интернета, - это и норм, сохранить к себе на диск. Но копить эту инфу годами и наполнять её для дальнейшего использования - конкретно для меня получилось проще это найти в сети.
А вы не пробовали сжимать json? У нас похожая проблема была, и в итоге просто добавили gzip. Определённо это не идеальное решение - размер всё равно больше чем avro/protobuf, зато со схемой проще - pojo файл конечно нужен, если мы хотим это сообщение использовать, но всегда можно на raw сообщение посмотреть, что бы понять что там вообще есть. А в хедере полное имя класса передаётся и по нему можно десериализовать.
А что бы универсально работало - gzip/string - есть magic number у gzip. Т.е. в топике просто байты, а на стороне клиента уже по первым 3 байтам понимается - это gzip или string.
Мы разные решения перепробовали и остановились на этом как наиболее универсальное - json сейчас все поддерживают - ui, backend, и человеком читается :-)
А почему markdown выбрали, а не asciidoc? Меня в md смущает собственно отсутствие md - каждый пилит собственный формат на основе него - GitHub, Obsidian, BitBucket ну и вы.