Этот набор советов рассчитан на джуниоров, но может быть полезна для любого разработчика, который заинтересован в культивировании хороших привычек. Я стараюсь постоянно ставить перед собой сложные задачи и выходить из зоны комфорта, здесь вы найдете выжимку из моего опыта в виде советов на каждый день. В свою очередь, можете предложить мне идеи, которые здесь не указаны — я стремлюсь постоянно совершенствовать свои техники и расти над собой.



Итак, приступим.

Новое место работы. Все собеседования позади. Первый рабочий день. Тебя проводят к рабочему месту. Там уже стоит готовый к работе ноутбук. Ты открываешь крышку. Все, ты готов к работе. Твоя первая задача. К тебе подходит человек, который должен ввести тебя в курс дела. Он объясняет тебе, что нужно сделать: баг с фиксом в 3 строчки кода. Попутно тебе помогают настроить рабочий комп. И вот ты уже приступаешь к задаче и понимаешь, что как-то все не так…

Во-первых, для сборки фронтенда у нормальных людей давно уже используется Webapck, на худой конец Gulp. Неужели они ничего не слышали про Docker?! Они вообще не умеют писать на Python!? Да и зачем здесь в принципе Python, и почему он еще 2й версии!? Вот дебилы! (Здесь может быть любой WTF на ваш вкус).

Мысли свои озвучиваешь вслух. Но про дебилов молчишь, конечно, все-таки культурный человек. Но на лице все написано. А вообще должны и сами понимать. И вроде все правильно. И все по делу. Но…

Два года назад MIT запустила платформу Moral Machine. Каждый желающий мог пройти тест из смоделированных 13 ситуаций: указать, как стоит вести себя беспилотному автомобилю и кем предпочтительней пожертвовать, когда потери неизбежны. За два года в исследовании приняли участие больше 2 млн людей со всего мира. Они предоставили 40 млн решений для смоделированных ситуаций.

Вчера MIT опубликовало результаты этого эксперимента.


Пример задания из теста. Тормоза беспилотного автомобиля отказали. Что предпочтительнее: сохранять курс (тогда погибнут трое пожилых людей, переходящих дорогу на красный свет) — или свернуть и врезаться в ограждение (погибнут двое взрослых людей и ребенок, находящиеся в машине)?

Сегодня у нас в виртуальной студии самый известный в мире докладчик по Spring — Джош Лонг.

Именно его докладами открываются Java-конференции по всему миру. Именно он отвечает на вопросы сообщества, делает Spring Tips на YouTube, именно его «This week in Spring» мы читаем каждую неделю и многое другое.

Кстати, Джош разрешил использовать все материалы в нашем собственном «This week in Java», но он делает их в таком объеме и глубине, что эти данные ни разу не получилось сжать до формата «дайджеста на 15 минут».

Иногда кажется, что он находится во всех городах одновременно, читает доклады и пишет статьи в один момент. Сегодня мы будем разбираться, как это у него получается. Узнаем про «юргенизацию кода», причины удивительной живучести Spring и то, как он умудрился прожить столько лет без глобальных переписываний всего с нуля и другие интересные фишки.

Участники

Josh Long, Spring Developer Advocate at Pivotal

Евгений Трифонов, Олег Чирухин — редакция JUG.ru Group

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

И в самом деле, в постгресе довольно большая куча всяких метрик, все они представлены в виде представлений и функций. С одной стороны это очень удобно, написал SELECT и получил данные. С другой стороны, такая периодическая писанина слегка утомляет.

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

Все мы часто пишем простые методы в контроллерах работающие через числовые идентификаторы.

    @RequestMapping(value = {"/entityName/{entityId}/get"}, method = RequestMethod.GET)
    @ResponseBody
    public Entity get(@PathVariable(value = "entityId") Integer entityId) {
        //возврат значения сущности по ID
    }

Пришедший ID надо валидировать.

(Иллюстрация)

Одна из задач, с которой сталкиваются 99,9% разработчиков, — это обращение к сторонним endpoint’ам. Это могут быть как внешние API, так и «свои» микросервисы. Сейчас все и вся бьют на микросервисы, да. Получить или отправить данные просто, но иногда изобретают велосипеды. Можете назвать 5 способов реализации запросов на Java (c использованием библиотек и без)? Нет — добро пожаловать под кат. Да? Заходите и сравните ;)

Все течет, все меняется, но только input[type=file] как портил нервы всем начинающим веб-разработчикам, так и продолжает это делать до сих пор. Вспомните себя N лет назад, когда вы только начинали постигать азы создания веб-сайтов. Молодой и неопытный, вы искренне удивлялись, когда кнопка выбора файла напрочь отказывалась менять цвет своего фона на ваш любимый персиковый. Именно в тот момент вы впервые столкнулись с этим несокрушимым айсбергом под названием «Загрузка файлов», который и по сей день продолжает «топить» начинающих веб-разработчиков.

На примере создания поля для загрузки файлов я покажу вам, как правильно прятать input[type=file], настраивать фокус на объекте, у которого фокуса быть не может, обрабатывать события Drag-and-Drop и отправлять файлы через AJAX. А также я познакомлю вас с парой браузерных багов и путями их обхода. Статья написана для новичков, но в некоторых моментах может быть полезна и занимательна даже для матерых разработчиков.

Добрый день, уважаемое Сообщество.

Разрабатывая многопользовательское web-приложение, столкнулся с проблемой многократного входа в систему (новый login при незавершенной старой сессии), решение которой потребовало необычного обходного маневра, чтобы сохранить логичную работу программы и ее понятный дизайн. В этой статье хочу поделиться c Вами опытом, осветив сперва традиционные подходы к управлению сессиями в Spring Security, и завершив обзор рацпредложением в виде 'костыля' собственной разработки.

Проблема контроля сессий актуальна для множества проектов. В моем случае это была игра (бэкенд на Java+Spring), где зарегистрировавшиеся пользователи могут выбирать с кем сразиться из списка присутствующих на сайте свободных игроков. После входа (login) игрока информация о нем добавляется в структуру данных в памяти. Часть этих данных асинхронно отображается в игровом интерфейсе, как список игроков, присутствующих на арене. Когда игрок выходит, то информация о нем должна быть сохранена в БД, удалена из структуры данных, и игрок более не будет отображаться в списке соперников online. Здесь возникали некоторые трудности из-за асинхронности, но не будем затрагивать их, ведь они лежат в стороне от темы статьи.

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

• он может добросовестно разлогиниться (нажав кнопку logout);
• может просто закрыть браузер, крышку ноутбука, нажать ресет и т.п., в общем уйти по-английски.

Уходим по-аглийски

Для таких 'английских' сценариев используется следующий подход.

1.  Добавляется SessionEventListener при регистрации DispatcherServlet в ходе стандартной инициализации и настройки Spring MVC приложения:

В чём идея сортировок выбором?

1. В неотсортированном подмассиве ищется локальный максимум (минимум).
2. Найденный максимум (минимум) меняется местами с последним (первым) элементом в подмассиве.
3. Если в массиве остались неотсортированные подмассивы — смотри пункт 1.

Spring Framework является одним из самых сложных фремворков для понимания и изучения. Большинство разработчиков изучают его медленно, через практические задачи и гугл. Этот подход не эффективен, так как не даёт полной картины и при этом требует больших затрат.

Я хотел бы предложить вам принципиально новый подход к изучению Спринга. Он заключается в том, что человек проходит через серию специально подготовленных туториалов и самостоятельно реализует функционал спринга. Особенность этого подхода в том, что он, помимо 100%-го понимания изучаемых аспектов Spring даёт ещё большой прирост в Java Core (Annotations, Reflection, Files, Generics).

Статья подарит вам незабываемые ощущения и позволит почувствовать себя разработчиком Pivotal. Шаг за шагом, вы сделаете ваши классы бинами и организуете их жизненный цикл (такой же, как и в реальном спринге). Классы, которые вы будете реализовывать — BeanFactory, Component, Service, BeanPostProcessor, BeanNameAware, BeanFactoryAware, InitializingBean, PostConstruct, PreDestroy, DisposableBean, ApplicationContext, ApplicationListener, ContextClosedEvent.

История разработки культовой игры-долгостроя S.T.A.L.K.E.R.: Shadow of Chernobyl, созданной украинской компанией GSC GameWorld и выпущенной в 2007 году, долгое время была окутана немалым количеством легенд. Причиной их появления было то, что в релизном варианте игра была слабо похоже на обещания, которые раздавали до этого игрокам — в силу вырезанного контента и возможностей теперь она напоминала скорее линейный шутер, чем амбициозную песочницу с открытым миром. Слухи утверждали, что виной всему — компания THQ, ответственная за издание игры на Западе.

За прошедшие десять с лишним лет многие из тайн прояснились. Различные участники событий поделились своими воспоминаниями; утекли всевозможные игровые билды; стали доступны исходники движка X-Ray Engine версии 1.6 (который был основательно проверен PVS-Studio); авторы многочисленных модов для игры постарались устранить недостатки игры, в том числе вернув вырезанный контент, и обеспечили ей долгую жизнь.

Сегодня портал Eurogamer опубликовал материал, основанный на проведенном недавно интервью с Дином Шарпом, работавшим на тот момент в THQ, — западном издателе S.T.A.L.K.E.R. — и дополненном фактами, поведанными Олегом Яворским (на тот момент — PR-менеджером GSC, ныне — Vostok Games). В нем откровенно рассказывается, что же на самом деле произошло со «Сталкером».

Для чего нужна реконструкция, если исходный код этого класса открыт?

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

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

Всем привет. В статье хочу описать свой эксперимент по созданию «искусственной жизни» на компьютере.

Как это выглядит?

картинка кликабельна

На компьютере создаётся виртуальная среда со своими правилами и выпускается первая простейшая живность. Буду называть их ботами. Боты могут погибнуть или выжить и дать потомство. Потомок может слегка отличаться от предка.

Ну а дальше за работу принимается эволюция и естественный отбор.

А мне остаётся только наблюдать за развитием мира.

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

Поведением ботов управляет код, записанный в них.

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

Внутреннее устройство кода — это самое интересное в проекте.

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

ДИСКЛЕЙМЕР

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

Здесь приводится опыт, который выдернул меня из состояния «читаю со словарем».



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

Возьмем такой предмет, как английский язык. Там куча понятий: 12 времен глагола, страдательный залог, причастия и т.п. Кто их ввел? Видимо, некие ученые мужи, для которых английский язык был РОДНЫМ. Они жили себе в каком-нибудь Oxford’e или в Cambridg’e и вряд ли знали русский язык.

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

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

Английская грамматика – туда же – что-то академическое и малополезное при изучении языка с нуля. Для человека, который более-менее свободно умеет стыковать из английских слов фразу, нужно просто учить новые слова.

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

Статья ориентирована именно на таких.

В Твиттере какое-то время назад запостили шутку в честь приобретения Майкрософтом ГитХаба — страницу сайта, перестилизованную в стиле Windows 98. Я решил, что шутка слишком хороша, чтобы оставаться шуткой.

Здравствуйте, коллеги. Сегодня хотели поинтересоваться, насколько востребованной вам кажется слегка устаревшая книга "Bayesian Methods for Hackers", опубликованная в оригинале в 2015 году, но пока не переведенная на русский язык.


Книга позиционируется как прикладная, максимально избавленная от математики и неустаревающая.

Под катом — немного сокращенный перевод обзора этой книги, выложенного автором на Github.
Поучаствуйте пожалуйста в голосовании

Всем привет. Я – айтишник «за 30», и я люблю английский язык. Так получилось, что на протяжении многих лет английский никак не хотел полюбить меня. Перед вами живой пример человека с «плохой памятью», «неспособностью к языкам», богатейшим опытом неудачного изучения английского как на курсах, так и самостоятельно, упущенными из-за незнания языка шансами и возникшими на этой почве комплексами. Все, что можно было сделать в изучении иностранного языка плохо, я попытался сделать еще хуже. Не смотря на все это, перед вами история с хэппи эндом, которая, верю, поможет кому-то избежать глупых ошибок, сэкономить время, избавится от иллюзий и предрассудков по поводу изучения нового языка с около нулевого уровня.

Нечеткая логика для управления

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

Постановка задачи

Рассмотрим синтез цифрового ПИД-регулятора и нечеткого регулятора для системы управления ракетой по углу атаки. Методом математического моделирования определим процессы в системе и дадим сравнительную оценку качества системы при использовании синтезированных регуляторов.

Читайте часть 1 вот тут.