Красный конструктор почему нельзя гуглить

Что гуглили в июле: мокрая коала, игра про котика и калорийность арбуза. Исследование TexTerra

Интересы россиян ко всякой всячине по предыдущим месяцам можно посмотреть тут – за март, апрель, май и июнь.

А вот как мы анализировали запросы – с помощью сервиса Google Trends.

• Выбрали период — последние 30 дней, страна — Россия.
• Сервис показал, какие запросы показали самый большой рост. Это значит, что интерес к указанным темам был не просто высоким, но и необычно высоким по отношению к предыдущему периоду.
• Если запросы попадали сразу в несколько категорий или дублировались по смыслу, мы упоминаем такие запросы в статье только раз.

Список лидеров по всем тематикам можно найти здесь .

Тренд на заготовки

Это странно, но запроса «куда деть кабачок» пока нет. Видимо, пока не кончились у кабачковладельцев знакомые, кому еще не задавали главный вопрос лета.

Зато очень много запросов про разное варенья! От 750 % до 1 450 % роста набрали запросы про варенье из абрикосов, малины, смородины, земляники, крыжовника и вишни. И еще желе из красной смородины: кстати, это лидер взрывного интереса среди заготовок — плюс 2 700 %.

А кто-то ловит момент, налегает на свежее… но беспокоится о фигуре: у запроса «сколько калорий в арбузе» рост 650 %. Мы тоже загуглили: самое высокое значение (видимо, для самых сладких арбузов) — всего 38 калорий. А большинство источников приводят еще меньшие цифры — от 25 до 30. Так что ешьте спокойно!

Вот он — символ второй половины лета
Никогда не гуглите…

Примерно под таким названием прошла публикация, которая взорвала пользователям мозг (и, конечно, все тут же пошли гуглить). Вот что оказалось «нельзя» искать в интернете:

• «мокрая коала» — рост запроса на 1 850 %;
• «суп в пустой комнате» — на 1 650 %;
• «конструктор красного цвета» — 200 %.

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

Мокрая коала. Страшно… страшно мило

А вот что действительно не стоит гуглить слабонервным, так это «chase no face» («Чейз без лица»). В июле запрос стал сверхпопулярным — все дело в кошке Чейз с травмированной мордочкой.

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

Море дает отпор

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

Вообще-то не такие уж они опасные, как пытался убедить нас Стивен Спилберг. Некоторые виды вообще не интересуются человеком как обедом. Но бывает и такое: вот, например, в Египте 1 июля акула откусила гражданке Австрии руку и ногу. Итог — смерть по дороге в больницу (у гражданки) и рост запроса «акула напала» до значения «сверхпопулярность» (у нас в России).

А чилийские рыбаки решили не ждать, пока кто-нибудь нападет, и сделали это сами: выловили длинную несимпатичную тварь под названием «сельдяной король», она же «ремень-рыба». Говорят, поймавшего ее ждут всяческие несчастья (а заодно и остальное человечество).

В общем, не зовите нас на вашу вечеринку, если она выглядит не так:

К селедке, кстати, «король» не имеет никакого отношения — общий у них только класс (лучеперые рыбы), а отряды уже разные: сельдеобразные и опахообразные соответственно

Запрос «сельдяной король», как нетрудно догадаться, стал сверхпопулярным.

Все пропало!

После новости о сельдяном короле самое время рассказать про запрос «как я умру» (рост на 130 %).

Мы загуглили — и да, это оказался очередной дурацкий тестик. Дурацкий, но именно за такими можно тупить до трех утра. Обидное.

Когда деморализованный юзер дочитывает пророчество до конца, он видит добивочку про Владимира. Ну, это уже слишком(

Еще из панических запросов июля — «код ошибки 60-01 сбербанк» (рост на 2 050 %). А это уже про обрушение сберовского приложения, которое попало во все отраслевые СМИ.

Милота года: котик с рюкзачком

Stray стал самой скачиваемой игрой в Steam — киберпанк про рыжего котика набирает 98 % положительных отзывов. Редкая критика в духе «это просто переоцененное инди» тонет в массе этих отзывов. Ну а что — это ведь котик, все любят котиков.

Рост запроса — от 180 % до 400 % в разных формулировках.

Вы уже сыграли?

Пожалуй, это самая забавная игра последних лет — тут можно мяукать, скидывать вещи со стола, бросаться людям под ноги. А если на кота надеть рюкзачок, то он смешно падает на бок. Видели когда-нибудь драму, которую разыгрывают настоящие коты, если нарядить их в одежку? Ну так вот создатели Stray не зря долго наблюдали за котами, живущими в студии, — все самые смешные кошачьи повадки они перенесли в игру.

Красный конструктор почему нельзя гуглить

Забыли пароль? Введите ваш е-мейл адрес. Вы получите письмо на почту со ссылкой для восстановления пароля.

Авторизация
Быстрая регистрация

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

Создать аккаунт

• Работа на Vamber
• Интересные факты
• 10% от рефералов
• ТОП авторов
• Работа без опыта

Авторизация
Быстрая регистрация

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

«Ледокол открытий»: как стать конструктором, инженером, изобретателем

На пути к Северному полюсу участников просветительской экспедиции «Ледокол открытий» сопровождали эксперты «Росатома». Начальник конструкторского отдела МОКБ «Марс» Сергей Смирнов на мастер-классе поделился мечтой — ​создать в госкорпорации «бюро изобретений», в котором свои перспективные идеи школьники будут доводить до ума с профессионалами. А также рассказал, как стать конструктором, овладеть тайными знаниями и сделать атомную карьеру.

О пути в профессию

Я учился в Московском институте электроники и математики по специальности «проектирование технологии радиоэлектронных средств». Из названия ясно, что это не конструкторская специальность. У нас на курсе вообще только один предмет был отчасти связан с конструкторским делом, большинство давали общую подготовку: электроника, программирование, математика и др.

На четвертом курсе института научный руководитель привел меня и еще нескольких ребят в МОКБ «Марс». Сказал: это хорошее предприятие, им нужны молодые специалисты, а вы сообразительные ребята. Я выбрал конструкторский отдел — ​и не пожалел. Там работали очень крутые инженеры, правда, в основном люди пожилые. Специалистов среднего возраста практически не было. И я уже на четвертом курсе стал работать там на полставки. Причем очень не хотел отставать от тех, кто работал на полную ставку: задерживался на работе, старался дома что-то доделать, что не успевал в бюро. Возможно, поэтому после окончания института моя карьера быстро пошла в гору.

Год с небольшим после вуза я работал инженером-конструктором третьей категории, потом получил вторую категорию, первую, и через три года меня уже назначили начальником бригады из восьми человек. Причем я перешел из бригады проектирования солнечных широкопольных датчиков в бригаду, которая конструирует электронные устройства. Нюансы пришлось осваивать буквально за пару месяцев, коллектив мне в этом очень помог. И вот я уже 13 лет работаю в МОКБ «Марс», из них восемь — ​руководителем. Два года назад стал начальником отдела.

Один из любопытных проектов нашего бюро, в котором я участвую, — ​создание медицинской техники. Мы делаем роботизированный многостепенной стол для нейтронной и фотонной терапии, который будет с высокой точностью позиционировать пациента под облучением для лечения онкологических заболеваний.

О конструкторских навыках

У «Марса» есть базовая кафедра в Московском авиационном институте, многие сотрудники бюро там преподают, и кафедра много лет поставляет нам молодых специалистов. Кто-то становится программистом, кто-то конструктором, кто-то схемотехником.

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

Во-вторых, я проверяю, насколько соискатели знают станки, технологии сборки — ​нельзя быть конструктором без досконального знания оборудования. В нашем отделе мы стремимся к тому, чтобы по чертежам, которые конструктор передал в производство, на 95–98 % все было изготовлено и собрано с первого раза. На оставшиеся проценты приходится человеческий фактор — ​все мы люди, все где-то можем ошибиться. Но опыт конструктора, даже самого молодого, должен быть достаточен, чтобы вписаться в наши жесткие нормативы.

Об инженерном языке

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

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

О бюро изобретений

Талантливых ребят в стране много. Проблема в том, что школьники не обладают достаточными компетенциями, знаниями и связями для того, чтобы реализовать свои изобретения. К сожалению, и в структуре «Росатома» пока нет такой организации, которая могла бы им в этом помочь.

Моя мечта — ​создать такое конструкторское бюро, в котором школьники, авторы перспективных изобретений, будут доводить их до ума с участием профессионалов отрасли. Профи помогут молодым не допустить глупых ошибок, не наступать на грабли. Если все это хорошо организовать, то российская наука выиграет. Ведь большинство заказчиков боятся того, чего еще ни разу не видели, не выделяют деньги на то, что нельзя пощупать. «Росатом» может сделать прототипы, за которыми придет финансирование. Моя мечта — ​создать такое бюро изобретений.

О тайных и явных знаниях

Был такой изобретатель в СССР ­— Генрих Альтшуллер. Он заметил, что этапы развития разных технических систем похожи, и предположил, что они развиваются по определенным законам. Провел анализ патентного фонда и выявил эти законы. Фактически стал родоначальником целой науки — ​теории решения изобретательских задач (ТРИЗ). Сейчас эта наука популярна во всем мире, но ­почему-то в России про нее начинают забывать. Мне кажется, что ТРИЗ — ​это особые тайные знания, которыми стоит поделиться со своими соотечественниками, и, как рекомендовал Генрих Альтшуллер, прежде всего со школьниками и студентами, которые эту теорию лучше впитывают и потом применяют в жизни.

Кстати, свои ТРИЗ существуют и для экономики, и для политики, их разработали последователи Альтшуллера для самых разных областей науки. Книги на эту тему легко найти в интернете и в книжных магазинах.

Об амбассадорах «Росатома»

Когда меня пригласили поучиться на амбассадора, я первым делом полез гуглить, что это такое. Потом были сомнения, смогу ли я им стать. Но обучение затянуло — преподавали отличные специалисты. Я выполнил все поставленные задачи одним из первых — и понеслось. В основном я общаюсь со школьниками и студентами, рассказываю им, что такое атомная отрасль, конструирование, та же ТРИЗ. В «Сириусе» вел многодневный мастеркласс, где познакомился с отличными ребятами, которые прямо

с упоением все это слушали. И здесь, на «Ледоколе открытий», мы со школьниками придумали несколько изобретений. Надеюсь, они их не забросят, доведут до ума, а я помогу им их идеи реализовать и запатентовать.

Что мы делаем не так со Спрингом

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

Надеюсь, вам будет интересно, а если после прочтения вы осознаете свои «грехи» и встанете на путь исправления, то я буду доволен вдвойне. Также призываю вас поделится своими собственными примерами в комментария, наиболее любопытные и необычные добавим в запись.

Autowired

Великий и ужасный @Autowired — это целая эпоха в Спринге. Без него до сих пор не обойтись при написании тестов, но в основном коде он (ПМСМ) явно лишний. В нескольких моих последних проектах его не было вовсе. Долгое время мы писали вот так:

@Component public class MyService < @Autowired private ServiceDependency; @Autowired private AnotherServiceDependency; //. >

Причины, по которым внедрение зависимостей через поля и сеттеры подвергаются критике, уже подробно описывались, в частности здесь. Альтернатива — внедрение через конструктор. По приведённой ссылке, описан такой пример:

private DependencyA dependencyA; private DependencyB dependencyB; private DependencyC dependencyC; @Autowired public DI(DependencyA dependencyA, DependencyB dependencyB, DependencyC dependencyC)

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

private DependencyA dependencyA; private DependencyB dependencyB; private DependencyC dependencyC; private DependencyD dependencyD; private DependencyE dependencyE; private DependencyF dependencyF; private DependencyG dependencyG; private DependencyH dependencyH; private DependencyI dependencyI; private DependencyJ dependencyJ; @Autowired public DI(/* . */)

Код прямо скажем, выглядит монструозненько.

И вот тут многие забывают, что и здесь скрипач @Autowired не нужен! Если у класса только один конструктор, то Спринг (>= 4) поймёт, что зависимости нужно внедрять через этот конструктор. А значит мы можем и его выбросить, заменив его на ломбоковский @AllArgsContructor . Или ещё лучше — на @RequiredArgsContructor , не забыв при этом объявить все нужные поля final и получив на сдачу безопасную инициализацию объекта в многопоточной среде (при условии, что все зависимости также безопасно инициализируются):

@RequiredArgsConstructor public class DI

Статические методы в утилитных классах и enum-функции

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

@UtilityClass public class ЧтоТоТамUtils < public static UserDto entityToDto(UserEntity user) < //. >>

Более продвинутые пользователи, читавшие умные книги, знают про волшебные свойства перечислений:

enum ЧтоТоТамFunction implements Function  < INST; @Override public UserDto apply(UserEntity user) < //. >>

Правда, и в этом случае обращение всё равно происходит к объекту-одиночке, а не к компоненту, управляемому Спрингом.
Ещё более продвинутые парни (и девушки) знают про MapStruct, позволяющий описать всё в виде одного-единственного интерфейса:

@Mapper(componentModel = "spring", unmappedTargetPolicy = ReportingPolicy.ERROR) public interface CriminalRecommendationMapper

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

И мало кто вспоминает дедовский, но тем не менее простой и рабочий способ получить управляемый спрингом преобразователь:

import org.springframework.core.convert.converter.Converter; @Component public class UserEntityToDto implements Converter  < @Override public UserDto convert(UserEntity user) < //. >>

Преимущество здесь в том, что в другом классе мне достаточно написать

@Component @RequiredArgsConstructor public class DI < private final ConverteruserEnityToDto; >

и Спринг самостоятельно всё разрулит!

Ненужный Qualifier

Случай из жизни: приложение работает с двумя БД. Соответственно, есть два источника данных ( java.sql.DataSource ), два менеджера транзакций, две группы репозиториев и т.д. Всё это удобно описать в двух отдельных настройках. Вот это для Постгре:

@Configuration public class PsqlDatasourceConfig < @Bean @Primary @ConfigurationProperties(prefix = "spring.datasource.psql") public DataSource psqlDataSource() < return DataSourceBuilder.create().build(); >@Bean public SpringLiquibase primaryLiquibase( ProfileChecker checker, @Qualifier("psqlDataSource") DataSource dataSource ) < boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(dataSource); liquibase.setChangeLog("classpath:liquibase/schema-postgre.xml"); liquibase.setShouldRun(isTest); return liquibase; >>

@Configuration public class Db2DatasourceConfig < @Bean @ConfigurationProperties(prefix = "spring.datasource.db2") public DataSource db2DataSource() < return DataSourceBuilder.create().build(); >@Bean public SpringLiquibase liquibase( ProfileChecker checker, @Qualifier("db2DataSource") DataSource dataSource ) < boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(dataSource); liquibase.setChangeLog("classpath:liquibase/schema-db2.xml"); liquibase.setShouldRun(isTest); return liquibase; >>

Поскольку у меня есть две базы, то для тестов я хочу накатить на них два отдельных DDL/DML-я. Поскольку обе конфигурации загружаются одновременно при поднятии приложения, то если я уберу @Qualifier , то Спринг лишится целеуказания и в лучшем случае свалится с ошибкой. Получается, что @Qualifier -ы громоздки и подвержены очепяткам, а без них не работает. Чтобы выйти из тупика нужно сообразить, что зависимость можно получать не только в виде аргумента, но и в виде возвращаемого значения, переписав код вот так:

@Configuration public class PsqlDatasourceConfig < @Bean @Primary @ConfigurationProperties(prefix = "spring.datasource.psql") public DataSource psqlDataSource() < return DataSourceBuilder.create().build(); >@Bean public SpringLiquibase primaryLiquibase(ProfileChecker checker) < boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(psqlDataSource()); // > //. @Configuration public class Db2DatasourceConfig < @Bean @ConfigurationProperties(prefix = "spring.datasource.db2") public DataSource db2DataSource() < return DataSourceBuilder.create().build(); >@Bean public SpringLiquibase liquibase(ProfileChecker checker) < boolean isTest = checker.isTest(); SpringLiquibase liquibase = new SpringLiquibase(); liquibase.setDataSource(db2DataSource()); // >

javax.inject.Provider

Как получить бин с областью действия prototype? Часто мне попадалось вот это

@Component @Scope(SCOPE_PROTOTYPE) @RequiredArgsConstructor public class ProjectBuilder < private final ProjectFileConverter converter; private final ProjectRepository projectRepository; //. >@Component @RequiredArgsConstructor public class PrototypeUtilizer < private final ProviderprojectBuilderProvider; void method() < ProjectBuilder freshBuilder = projectBuilderProvider.get(); >>

Казалось бы, всё хорошо, код работает. Однако, в этой бочке мёда есть ложка дёгтя. Нам нужно тащить за собой ещё одну зависимость javax.inject:javax.inject:1 , которая была добавлена в Мавен Централ ровно 10 лет назад и с тех пор ни разу не обновлялась.

А ведь Спринг давным давно умеет делать то же самое без сторонних зависимостей! Достаточно заменить javax.inject.Provider::get на org.springframework.beans.factory.ObjectFactory::getObject и всё работает точно так же.

@Component @RequiredArgsConstructor public class PrototypeUtilizer < private final ObjectFactoryprojectBuilderFactory; void method() < ProjectBuilder freshBuilder = projectBuilderFactory.getObject(); >>

Теперь мы можем с чистой совестью выпилить javax.inject из списка зависимостей.

Использование строк вместо классов в настройках

Часто встречающийся пример подключения Spring Data -репозиториев к проекту:

@Configuration @EnableJpaRepositories("com.smth.repository") public class JpaConfig < //. >

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

@Configuration @EnableJpaRepositories(basePackageClasses = AuditRepository.class) public class JpaConfig < //. >

Здесь AuditRepository — один из репозиториев пакета, который мы будем просматривать. Т. к. мы указали класс, то нам потребуется подключить этот класс к нашей конфигурации, и теперь опечатки будут выявляться прямо в редакторе или на худой конец при сборке проекта.

Этот подход можно применить во многих похожих случаях, например:

@ComponentScan(basePackages = "com.smth")

import com.smth.Smth; @ComponentScan(basePackageClasses = Smth.class)

Если нам нужно добавить некоторый класс в словарь вида Map , то это можно сделать вот так:

void config(LocalContainerEntityManagerFactoryBean bean)

но лучше использовать явный тип:

import com.smth.interceptor.AuditInterceptor; void config(LocalContainerEntityManagerFactoryBean bean)

А когда есть нечто вроде

LocalContainerEntityManagerFactoryBean bean = builder .dataSource(dataSource) .packages( //. пакеты с сущностями хибернейта ) .persistenceUnit("psql") .build();

то стоит обратить внимание, что метод packages() перегружен и использовать классы:

Не кладите все бины в один пакет

Думаю, во многих проектах на Спринге/Спринг Буте вы видели подобную структуру:

root-package | \ repository/ entity/ service/ Application.java

Здесь Application.java — это корневой класс приложения:

@SpringBootApplication @EnableJpaRepositories(basePackageClasses = SomeRepository.class) public class Application < public static void main(String[] args) < SpringApplication.run(Application.class, args); >>

Это классический код микросервиса: составляющие разложены по папочкам согласно назначению, в корне лежит класс с настройками. Пока проект небольшой, то всё хорошо. По мере разрастания проекта возникают жирненькие пакеты с десятками репозиториев/сервисов. И если проект так и останется монолитом, то б-г с ними. А вот если встанет задача разделить раскабаневшее приложение на части, тут-то и начинаются вопросы. Один раз испытав эту боль я решил применить другой подход, а именно группировать классы по их домену. В итоге получается что-то вроде

root-package/ | \ user/ | \ repository/ domain/ service/ controller/ UserConfig.java billing/ | \ repository/ domain/ service/ BillingConfig.java //. Application.java

Здесь пакет user включает в себя подпакеты с классами, ответственными за логику пользователей:

user/ | \ repository/ UserRepository.java domain/ UserEntity.java service/ UserService.java controller/ UserController.java UserConfig.java

Теперь в UserConfig можно описать все настройки, связанные с данным функционалом:

@Configuration @ComponentScan(basePackageClasses = UserServiceImpl.class) @EnableJpaRepositories(basePackageClasses = UserRepository.class) class UserConfig

Преимущество такого подхода в том, что модули можно будет при необходимости легче выделять в отдельные сервисы/приложения. Также это полезно в том случае, если вы собираетесь модуляризировать ваш проект, добавив module-info.java , скрыв от внешнего мира служебные классы.

На этом всё, я надеюсь, моё творчество оказалось для вас полезным. Описывайте в комментариях ваши антипаттерны, будем разбираться вместе 🙂