Новый релиз Laravel 5.5 станет релизом долгосрочной поддержки (Long Term Support, LTS). Это значит, что он будет получать правки багов в течение 2х лет, а обновления безопасности — в течение 3х. Таким же был релиз Laravel 5.1, но его двухгодичный срок правок подходит к концу в этом году. Давайте посмотрим без лишней суеты, что нас ждет в новой версии.
Когда приложение, использующее Redux, разрастается до достаточно больших размеров, количество состояний увеличивается многократно. Для разделения редьюсеров на логические единицы применяется подход комбинирования их с помощью combineReducers. Данное решение позволяет расширить store по «вертикали». Но бывают случаи, когда данного разделения может быть недостаточно. Например, один из уровней несет в себе составную логику, которую тоже было бы неплохо разделить (или как говорил один из известных людей: «Ухлубить!»). Но такого подхода нет в API Redux. И поиск решения данного вопроса так же ничего не дал (может плохо искал). Поэтому я разработал свой подход расширения по «горизонтали» Redux Store.
import {stateCombine, runCombine, getInitialState} from "redux-combine-deep-props";
Вы решили заняться разработкой мобильных игр. С чего начать? Большинство программистов в геймдеве не ходили в учебные заведения, специализирующие только на играх. Скорее, это был какой-нибудь аналог GeekUniversity с видеоуроками или самостоятельный путь, начавшийся с огромного количества любимых игр, разбора механики, курсов в целом по мобильной разработке, оттачивания найденных алгоритмов в простых игрушках, создаваемых для первого портфолио.
Вне зависимости от выбранного пути, рано или поздно появится необходимость подключить еще один источник знаний, и тут вы можете задуматься о книгах. Учитывайте, что ни одна книга по мобильной разработке не заменит практику. В больших статьях по геймдеву вы слово «книга» можете вообще не встретить. Однако книги имеют определенное преимущество по сравнению со статьями — легко отсортировать их по рейтингу и выбрать лучшие.
Итак, книги не заменят вам реальные боевые курсы, но они могут стать хорошим подспорьем и дополнительным источником знаний. Из книг выбираем лучшие, а далее сортируем по вашему языку и области применения.
Несмотря на то, что мы активно работаем с Python и Go, всё же существенная часть нашего серверного кода написана на PHP. Поэтому мы внимательно следим за всеми нововведениями языка. Прошло меньше года после релиза предыдущей минорной версии, и вот уже последний бета-релиз запланирован на 17 августа. Его ещё не рекомендуется использовать в production, но уже можно скачать docker-образ. Пора разбираться, что изменилось в новой версии языка.
Одномерная линейная регрессия — один из самых простых регрессионных методов (и вообще один из самых простых методов машинного обучения), который позволяет описывать линейную зависимость наблюдаемой величины от одного из признаков. В общем случае в задачах машинного обучения приходится сталкиваться с большим количеством различных признаков; одномерная линейная регрессия в таком случае выбирает тот из них, который позволяет добиться наилучшей корреляции с целевой функцией.
В предыдущем посте из этой серии мы обсудили точность вычислений средних и ковариаций, а также познакомились с методом Уэлфорда, который во многих случаях позволяет избежать вычислительных погрешностей в этих задачах. Сегодня мы рассмотрим практическое применение метода Уэлфорда в задаче одномерной линейной регрессии.
Если вы много занимаетесь отладкой приложений под Windows — вы, возможно, слышали о таком замечательном механизме, как Image File Execution Options (IFEO). Одна из предоставляемых им возможностей позволяет отлаживать приложение в условиях, более приближенных к боевым. Записав в нужное место в реестре специальный ключик, мы можем вместо программы автоматически запускать её отладчик, позволяя ему делать свои отладочные дела. Однако кто сказал, что этот механизм (фактически — перехвата запуска чего угодно) можно использовать только в подобных целях? Эта статья вовсе не об использовании вещей по назначению.
Под катом рассказ о том, как я попытался выжать побольше из этого механизма в своих добрых целях, и какие подводные камни мне встретились на пути. А у меня тут хорошие, отборные камни.
При создании value-объекта для хранения времени, я рекомендую выбирать вместе с экспертами в предметной области и вокруг нее с какой точностью он будет храниться.
Моделируя работу с числами считается хорошим тоном указывать точность. Неважно о чем идет речь — о деньгах, размере или весе; округляйте до заданного десятичного знака. Наличие округления делает данные предсказуемее для обработки и хранения, даже если это число только для отображения пользователю.
К сожалению, так делают не часто, и, когда приходит момент, проблема дает о себе знать. Рассмотрим следующий код:
$estimatedDeliveryDate = new DateTimeImmutable('2017-06-21');
// представим, что сегодня ТАКЖЕ 2017-06-21
$now = new DateTimeImmutable('now');
if ($now > $estimatedDeliveryDate) {
echo 'Package is late!';
} else {
echo 'Package is on the way.';
}Ожидаемо что, что 21 июня этот код выведет Package is on the way., ведь день еще не закончился и пакет, например, доставят ближе к вечеру.
Несмотря на это код так не делает. Так как не указана часть со временем, PHP заботливо подставляет нулевые значения и приводит $estimatedDeliveryDate к 2017-06-21 00:00:00.
С другой стороны $now вычисляется как… сейчас. Now включает в себя текущий момент времени, который, скорее всего, не полночь, так что получится 2017-06-21 15:33:34 или вроде того, что будет позднее, чем 2017-06-21 00:00:00.
