Лупить по Wildberry за контрафакт - это все-равно, что наказывать директора колхозного рынка. Наказывать надо продавцов. И наказывать не удалением товарок с полок, а уголовными делами. И минпромторг не собачиться должен с Дикой Ягодой, а дружить с ней и целовать ее в попу, и с ее помощью штамповать уголовные дела пачками и сажать ворье.
nullFree - ужасное, высосанное из пальца требование. null существует с одной целью - показать, что объекта нет. Не текст пустой, а нет объекта текста, по разным причинам.
Ну да, конечно. Вместо проверок a != null у нас везде будут проверки !a.isBlank(). Плюс еще придется придумывать, как различать случаи, когда текст не найден от текст имеется, но он пустой.
Программист должен решать задачу так, как решит руководитель группы. Если исполнитель не укладывается при решении задачи в тот срок, который запланировал руководитель группы - это косяк и ответственность руководителя. Не умеешь планировать работу подчиненных - сдай спецовку.
Ну давайте сравним с работой конструктора. Работал я инженером-технологом. Могу сказать. Никто и никогда не спрашивает ни инженера, ни конструктора, за какой срок он разработает техпроцесс или чертеж. Планированием занимаются начальники бюро и отделов. Они знают и умеют планировать работу бюро и отдела. И методов оценки трудоемкости разработки детали или техпроцесса тоже множество - количество отверстий, количество плоскостей и так далее. Всегда можно оценить сложность детали и привязать к ней трудоемкость. И ответственность за срыв сроков проектирования/отехнологичивания несут начальники (при Сталине их даже расстреливали) - и это правильно. Нигде в промышленности менеджеры проектов, продаваны и прочая бессмысленная братия не насилует работнику мозги насчет сроков, не стоит над душой, не нагоняет стресс на планерках, не подходит и с наездом говорит "что я еще могу сделать, чтобы ты быстрее сделал эту задачу".
Надо сказать прямо и честно. Проблема ИТ в плане планирования сроков и трудоемкости стоит не оттого, что ИТ какая-то особенная сфера, а оттого, что в ИТ доминируют безграмотные кадры, не имеющие высшего технического образования (я имею в виду настоящего инженерного, производственного). Никто из айтишников (я гарантирую вам это!) совершенно не имеет представления о промышленном производстве. Не имеет представления о конструкторской разработке, о технологии. Максимальный потолок для айтишного кадра - радиофак. Большинство же - курсы по джава и спрингу.
О каком планировании может идти речь? Для большинства айтишников (не для производственного инженера!) планирование производства (а разработка софтины в плане планирования производства абсолютно ничем не отличается от разработки ракеты, я гарантирую вам это!) - это магия, тайна, что-то за гранью понимания.
Почему об этом справшивают у работника? На заводе (в нормально производтвенном процессе) этим вопросом занимается экономист и нормировщик. И инструментов у них, чтобы запланировать трудоемкость изготовления детали - множество.От справочников до фотографирования. Виновата индустрия, а не работники. Если бизнес не умеет планировать трудоемкость техпроцесса - это проблема и вина бизнеса.
Увы, код, который комментирует сам себя, невозможно читать.
По элементарной, хотя бы причине: идентификаторы (имена) методов (да и вообще всего), должны ИДЕНТИФИЦИРОВАТЬ методы, то есть, отличать их друг от друга, а не описывать их. Имена банально должны быть как можно короче, чтобы ими пользоваться, если имена будут описывать сами себя, то они будут на несколько строк длиной.
В интерфейсе Posts создаете метод GetPostsByбизнес-условие. В реализации PgPosts РУЧКАМИ с помощью jdbc реализуете выборку из таблицы. Что не сработает?
ОРМ (и JPA) типа облегчает процесс работы для простых выборок и CRUD. Для сложных выборок из нескольких таблиц с кучей условий (что и является предметом работы энтерпрайз-программиста), hibernat или jpa превращается в срань, намного худшую, чем работа с читым SQL. Потому что SQL - всем известный стандарт, а всякие HQL-ли - самодельные птичьи языки, которые ТИПА упрощают работы с sql. Плюс всякие сраные глюки от хиберната, вроде недавнего (и не знаю, пофиксенный ли), когда первая выборка работает нормально, а при всех последующих приложение падает.
Единственный плюс hibernat - одинаковость HQL для разных баз, SQL может незначительно различаться.
Вообще, пользоваться его кабинетом без разрешения, только на основании того, что он с вами не скандалил по этому поводу - это просто безобразие. Начинать нужно с этого, а не с того, что он вас наругал.
Вы не думали никогда, что вообще-то, человеку приходится терпеть такое хамство? Это неприятно, это раздражает, это накапливает негатив. Неприятно, когда соседи или коллеги пользуются твоим. "А чо такова, он же не скандалил?".
А потом, когда это рано или поздно (совершенно закономерно и тащемта, справедливо) прорывается, начинаются обидки "Нормально же общались".
"Порка", блджад. Надо же, обиделись из-за того, что сидели в его кресле и человек вскипел. А дальше что? Будете писать, как начальник вас отматерил на виду у всех за то, что вы воруете в офисе?
Дальше эту простыню не читал. Аффтар, походу, пытается убедить свою совесть, что он (автор), вовсе не м...к, это начальник неправильно делает.
Дружище. QR- это насилие. Насилие в любом обществе - привилегия ТОЛЬКО государства. И направлено только в одном направлении - от государства к гражданину. Обратный вектор будет безжалостно рубиться даже при одном легком намеке.
Можно даже так сказать: "незаменимых нет, есть те, которых жалко потерять".
Лупить по Wildberry за контрафакт - это все-равно, что наказывать директора колхозного рынка. Наказывать надо продавцов. И наказывать не удалением товарок с полок, а уголовными делами. И минпромторг не собачиться должен с Дикой Ягодой, а дружить с ней и целовать ее в попу, и с ее помощью штамповать уголовные дела пачками и сажать ворье.
nullFree - ужасное, высосанное из пальца требование. null существует с одной целью - показать, что объекта нет. Не текст пустой, а нет объекта текста, по разным причинам.
"Только ситхи возводят все в абсолют".
Ну да, конечно. Вместо проверок a != null у нас везде будут проверки !a.isBlank(). Плюс еще придется придумывать, как различать случаи, когда текст не найден от текст имеется, но он пустой.
В промышленном производстве оценкой времени занимаются нормировщики и экономисты. И все прекрасно работает. И только в айти полная ахинея.
Программист должен решать задачу так, как решит руководитель группы. Если исполнитель не укладывается при решении задачи в тот срок, который запланировал руководитель группы - это косяк и ответственность руководителя. Не умеешь планировать работу подчиненных - сдай спецовку.
Ну давайте сравним с работой конструктора. Работал я инженером-технологом. Могу сказать. Никто и никогда не спрашивает ни инженера, ни конструктора, за какой срок он разработает техпроцесс или чертеж. Планированием занимаются начальники бюро и отделов. Они знают и умеют планировать работу бюро и отдела. И методов оценки трудоемкости разработки детали или техпроцесса тоже множество - количество отверстий, количество плоскостей и так далее. Всегда можно оценить сложность детали и привязать к ней трудоемкость. И ответственность за срыв сроков проектирования/отехнологичивания несут начальники (при Сталине их даже расстреливали) - и это правильно. Нигде в промышленности менеджеры проектов, продаваны и прочая бессмысленная братия не насилует работнику мозги насчет сроков, не стоит над душой, не нагоняет стресс на планерках, не подходит и с наездом говорит "что я еще могу сделать, чтобы ты быстрее сделал эту задачу".
Надо сказать прямо и честно. Проблема ИТ в плане планирования сроков и трудоемкости стоит не оттого, что ИТ какая-то особенная сфера, а оттого, что в ИТ доминируют безграмотные кадры, не имеющие высшего технического образования (я имею в виду настоящего инженерного, производственного). Никто из айтишников (я гарантирую вам это!) совершенно не имеет представления о промышленном производстве. Не имеет представления о конструкторской разработке, о технологии. Максимальный потолок для айтишного кадра - радиофак. Большинство же - курсы по джава и спрингу.
О каком планировании может идти речь? Для большинства айтишников (не для производственного инженера!) планирование производства (а разработка софтины в плане планирования производства абсолютно ничем не отличается от разработки ракеты, я гарантирую вам это!) - это магия, тайна, что-то за гранью понимания.
Почему об этом справшивают у работника? На заводе (в нормально производтвенном процессе) этим вопросом занимается экономист и нормировщик. И инструментов у них, чтобы запланировать трудоемкость изготовления детали - множество.От справочников до фотографирования. Виновата индустрия, а не работники. Если бизнес не умеет планировать трудоемкость техпроцесса - это проблема и вина бизнеса.
Профессионалы на дороге не валяются. Их приходится выдергивать у конкурентов за зарплаты, превышающие рыночные.
А теперь добавьте еще три-четыре условия в if и попробуй отразить это в имени. В энтерпрайзе не бывают простых примеров.
Увы, код, который комментирует сам себя, невозможно читать.
По элементарной, хотя бы причине: идентификаторы (имена) методов (да и вообще всего), должны ИДЕНТИФИЦИРОВАТЬ методы, то есть, отличать их друг от друга, а не описывать их. Имена банально должны быть как можно короче, чтобы ими пользоваться, если имена будут описывать сами себя, то они будут на несколько строк длиной.
Планеты надо покорять с такими людьми.
В интерфейсе Posts создаете метод GetPostsByбизнес-условие. В реализации PgPosts РУЧКАМИ с помощью jdbc реализуете выборку из таблицы. Что не сработает?
ОРМ (и JPA) типа облегчает процесс работы для простых выборок и CRUD. Для сложных выборок из нескольких таблиц с кучей условий (что и является предметом работы энтерпрайз-программиста), hibernat или jpa превращается в срань, намного худшую, чем работа с читым SQL. Потому что SQL - всем известный стандарт, а всякие HQL-ли - самодельные птичьи языки, которые ТИПА упрощают работы с sql. Плюс всякие сраные глюки от хиберната, вроде недавнего (и не знаю, пофиксенный ли), когда первая выборка работает нормально, а при всех последующих приложение падает.
Единственный плюс hibernat - одинаковость HQL для разных баз, SQL может незначительно различаться.
Мне не нравится слово "погружение". Более правильно "разобраться с этим дерьмом".
Сколь бы то ни было маленькая вероятность не может быть нулевой.
Это шутка, да?
Плюсы со временем превратятся в то, что уже было тридцать лет назад - в Дельфи.
Какая хорошая статья! Я плакал на некоторых моментах.
Вообще, пользоваться его кабинетом без разрешения, только на основании того, что он с вами не скандалил по этому поводу - это просто безобразие. Начинать нужно с этого, а не с того, что он вас наругал.
Вы не думали никогда, что вообще-то, человеку приходится терпеть такое хамство? Это неприятно, это раздражает, это накапливает негатив. Неприятно, когда соседи или коллеги пользуются твоим. "А чо такова, он же не скандалил?".
А потом, когда это рано или поздно (совершенно закономерно и тащемта, справедливо) прорывается, начинаются обидки "Нормально же общались".
"Порка", блджад. Надо же, обиделись из-за того, что сидели в его кресле и человек вскипел. А дальше что? Будете писать, как начальник вас отматерил на виду у всех за то, что вы воруете в офисе?
Дальше эту простыню не читал. Аффтар, походу, пытается убедить свою совесть, что он (автор), вовсе не м...к, это начальник неправильно делает.
Дружище. QR- это насилие. Насилие в любом обществе - привилегия ТОЛЬКО государства. И направлено только в одном направлении - от государства к гражданину. Обратный вектор будет безжалостно рубиться даже при одном легком намеке.