В автоматизации отчетности очень часто используют открытую Java-библиотеку JasperReports, например статья Опенсорс-решение для автоматизации отчетности рассказывает об ее использовании для получения PDF форматов отчетности между делом упомянув о возможности экспорта в другие форматы.

Однако нередко возникает потребность получать данные не в твердой копии, а в форматах электронных таблиц и в этом направлении в библиотеке JasperReports есть мощный инструмент Crosstab. Вместе с механизмом экспорта в форматы электронных таблиц данный инструмент может быть востребован для получения форматированных документов, которые годны как отчеты для анализа, так и для дальнейшей обработки данных.

Основная цель использования печатной формы - выгрузка данных в электронные таблицы для дальнейшего использования данных. Разработку печатной формы будем делать в среде TIBCO Jaspersoft® Studio

Два с половиной года назад я перешел из отрасли автоматизации промышленного оборудования, в которой я проработал почти 25 лет, в сферу банковского IT, разработчиком Java, и достиг (по оценке моего лида) уровня middle ++.

Кардинально сменить сферу деятельности в 45 было непростым решением и еще более непростым в реализации, путь был трудным, долгим и на нем пришлось много и часто платить – деньгами, свободным временем и постоянной сложной мозговой активностью. Не всем это под силу, но если вы решились идти в IT в середине своего жизненного пути, то я хотел бы вам помочь - поделиться полезными советами, развеять страхи и сомнения.

Если данная тема заинтересует хаброжителей - я могу написать подробную историю, почему и как я это сделал, пока ограничусь сухой выжимкой (исключив негативные моменты, мои личные переживания и прочую лирику).

Предисловие

Что это

Перевод статьи подготовлен специально для студентов курса "MS SQL Server разработчик".

Содержание

• Ошибка #1: Предполагать, что значения даты и времени хранятся в виде форматированных строк
• Ошибка #2: Забыть о людях, которые живут в других частях света
• Ошибка #3: Снова забыть о людях, которые живут в других частях света
• Ошибка #4: Относиться к DATETIME2 только как к более точному DATETIME
• Ошибка #5: Игнорировать округление даты/времени
• Ошибка #6: Делать лишнюю работу для удаления времени из полной даты
• Ошибка #7: Не понимать как работает функция DATEDIFF
• Ошибка #8: Небрежно относиться к условиям поиска
• Ошибка #9: Забыть о диапазонах в типах данных для даты/времени
• Ошибка #10: Не использовать преимуществ функций работы с датой и временем

Недавно в корпоративном блоге Parallels выходила статья, где приводились размеры оплаты труда разработчиков на западе со словами "в любом случае российские зарплаты пока не дотягивают до европейских". Частое столкновение с тем, как люди очень выборочно сравнивают условия жизни поросенка Петра и тех, кто не уехал, побудили поделиться некоторыми наблюдениями о жизни в США изнутри. Цель данного поста — подтолкнуть подходить к вопросу комплексно и делать сравнение яблок с яблоками, а не точечно сравнивать то, что выгодно, и закрывать глаза на остальные важные аспекты. Если вам покажется, что в данной статье есть иные подтексты — прошу списать это на то, что "чукча — не писатель" и по возможности игнорировать их.

В жизни разработчика наступает момент, когда он начинает проводить код-ревью. Как правило, это один из признаков роста программиста: к его мнению начинают по-настоящему прислушиваться и доверять более серьезные задачи. Конкретный момент, когда разработчику предлагают заняться ревью зависит от структуры компании: есть команды, где это могут делать более-менее все по истечению некоторого времени работы, а есть такие, где процесс ревью целиком лежит на самых старших и опытных коллегах.

Вместе с тем, редко кто рассказывает о том, каких принципов необходимо придерживаться для проведения качественного ревью: каковы главные цели этой процедуры, за чем смотреть в первую очередь, насколько быстро его нужно проводить.

Всвязи с этим, "Руководство компании Google по проведению ревью" выглядит очень ценным документом, перевод первой части которого и представлен далее. Переводы остальных частей выйдут позже отдельными постами. Стоит отметить, что это адаптированный перевод, не все переведено слово-в-слово, во имя более русских формулировок и предложений.

Терминология:

CL: "changelist" — список изменений кода, отправленный в систему контроля версий на ревью. Аналог Pull Request в GitHub или Merge Request в GitLab.

• начну писать код, а в процессе пойму, что да как;
• почитаю форумы, хабр, medium, stack overflow, книгу, записи на стенах, знаки свыше…;
• поспрашиваю у коллег, может, кто-то знает, как решить подобную задачу;
• начну рисовать квадратики и схематично покажу, какое видение задачи сформировалось у меня в сознании.

Низкая производительность труда в России

Система 5С Юрского периода

Интро

К сожалению, большая часть работы тимлида скрыта от команды. И в зависимости от многочисленных факторов, таких как размер команды, выстроенные процессы, наличие других ролей, занимающихся работой с командой — она еще и невероятно размыта. Список твоих обязанностей в разных компаниях будет отличаться. Где-то это просто формальная должность человека, который просто перетаскивает задачи из одного статуса в другой в свободное время от написания кода, в другой — это полноценная роль, где придется отложить в сторону свою любимую IDE и заняться кучей других обязанностей. Кстати, очень часто эту роль совмещают с еще одной ролью, техлида, и далеко не всегда это плохо.

Но один момент не меняется — если ты стал тимлидом, в твоей жизни изменится многое, если этого не произошло, это первый знак, говорящий о том, что ты явно не справляешься со своими обязанностями (либо это звание носит сугубо формальный характер).

Если ты никогда раньше этим не занимался, тебе предстоит свой долгий и тернистый путь с огромным количеством разбросанных граблей, на которые тебе придется наткнуться и без поддержки команды, увы, этот путь преодолеть будет невозможно.

Low-code платформы (Low code application platforms, LCAP) возникли как реакция на сложность и многообразие современных средств разработки ПО.

Согласно Gartner, одним из самых известных игроков в этой области является Mendix. Продажа Siemens за космические $700 млн. это подтверждает. Так что я буду использовать эту платформу как пример, хотя аналогичные выводы будут верны и для Outsystems, Appian, Kony, Betty Blocks и других.

Итак, ориентируя продажи на топ-менеджеров, вендоры low code платформ обещают, что даже простые пользователи смогут самостоятельно создавать бизнес-приложения.

То есть разработчики больше не нужны?!