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

Ключевые слова — AWS + Terraform + kops . Если это полезно мне — возможно будет полезно кому-нибудь еще. Добро пожаловать в комментарии.

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

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

Доброго времени суток. Хоть это не срок, но последние лет восемь я занимался практически только вебом. Работа в интернет-агентстве (раньше это называлось более приземленно — веб-студия), уход на фриланс, работа по контракту с различными ребятами из Америки/Европы, попытки написать свой золотой стартап.

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

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

Доброго времени суток. Давно хотелось написать про что-то больше, нежели чем WP. Заметил, что чем больше пытаешься прогрессировать, как разработчик, тем тривиальней кажется то, о чем хочешь написать. Но да ладно, возможно кому-то будет довольно полезен мой опыт. Цикл заметок будет ориентирован в первую очередь на тех, кто только начинает собирать свои первые реалтайм веб-приложения.

Итак, стоит задача синхронизации того, что видит пользователь и того, что есть в бд. Ранее для подобных задач использовал сервис Pusher, но, в последнее время, предпочитаю использовать Centrifuge. Предвосхищу вопрос о том, чем лучше это обычной связки redis/socket.io/node.js. Из коробки приватные каналы, простая интеграция, масштабирование, api, история сообщения в канале, события отписки и подписки пользователей на канал и много другое, что позволяет крайне быстро построить нужный прототип приложения, без раздувания стека технологий. Это работает для меня, у каждого свой путь. Кстати, язык на бекенде — php, и, соответственно, на фронтенде — js.

Что из этого получилось, некоторые нюансы — можете посмотреть ниже.

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

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

При разработке проекта для транспортной компании, занимающейся пассажирскими перевозками, возникла задача реализовать свой аналог Google Calendar для встраивания внутрь системы.
В силу некоторых причин(глубокая интеграция в проект, связь с кучей разных сущностей, полный контроль над всеми частями кода и прочее), использовать решение от Google было нерационально со многих точек зрения.

Итак, условия задачи:

1. Интерфейс должен быть максимально приближен к интерфейсу от Google (т.к. до этого использовали его)
2. Нормальная реализация RFC 2445, его части касательно RRULE (паттернов повторения)
3. Быстрая скорость просчета дат событий (в данном случае рейсов) и их рендер в браузере
4. Максимальное использование существующих библиотек для уменьшения потраченного времени .

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