Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
Круто!
Интересно было бы почитать про SVG и Angular.
Интересно было бы почитать про SVG и Angular.
> Так же друзья, если интересно, можем начать серию технических статей по стеку используемых технологий, а именно node.js, mongodb, redis, sockets, angular, svg и т.п.
Начинайте прямо сейчас :)
Начинайте прямо сейчас :)
Не понял одно, это будет какое-то приложение, которое нужно развернуть у себя, или это именно сервис? Или вы «сам себе провайдер»?
Это сервис, в котором можно мышкой сконструировать себе бекенд, настроить его и запустить в жизнь. А если есть какие то предпочтения по хостингу — амазон или что нибудь другое — то это можно настройками выбрать. В принципе мы являемся прослойкой между хостингом и разработчиком, делая последним жизнь проще.
Довольно интересно, хороший материал.
Ребят, шикарно!
Реально хочу попользоваться когда допилите, причем если понравится, думаю даже абонентку платить готов. Только не перемудрите с монетизацией.
Реально хочу попользоваться когда допилите, причем если понравится, думаю даже абонентку платить готов. Только не перемудрите с монетизацией.
Спасибо. А мы хотим как можно быстрее допилить. А можете посоветовать что нибудь, чего на первый взгляд не хватает, или например — какая модель монетизации была бы ближе всего? Или например какие сервисы тестирования можно было бы подключить, и CI. Хотелось бы набрать побольше отзывов, для дальнейшего развития.
Jenkins & Teamcity нужны просто обязательно
Sphinx и было б круто какие-либо cmf.
Как вариант, интеграцию с Redmine.
Как вариант, интеграцию с Redmine.
Ну пока зверь новый, е понятно чем его кормить и где выгуливать, но посмотрим. На данный момент разве что из мыслей как-то подружить Trello со всей этой радостью, но понимания зачем и как это сделать еще нет.
Как вариант, можете попробовать интегрироваться в продукты Atlasian
А можно как-то это у себя развернуть, а то получается на сторону отдаются доступ к серверам.
Это всё отлично, но надо же хоть ориентировочную стоимость писать… наверняка же вы этот момент уже продумывали.
Без соотношения цены/устранённого головняка картина не полная…
Без соотношения цены/устранённого головняка картина не полная…
В данный момент мы на этапе разработке и скорейшего выхода в открытую бету. Точная ценовая политика будет понятна только к официальному релизу. Мы хотим что бы сервисом пользовались как крупные корпоративные компании так и независимые разработчики. В свою очередь, хотелось бы услышать ваши пожелания по приемлимой для вас политике ценообразования. Для примера можно привести какой нибудь проект.
Ну вот смотрите, как пример. Пусть будет сферическое приложение на node. Пусть не нагруженное, но хочется надёжное.
1 Load balanser
2 node.js (meteor.js)
3 MongoDB cluster
Всего — 6 сферических машинок. Предположим, проект только стартует и ему с головой хватит 5-10-долларового DO. Выходит 30-60 долларов/месяц.
Например, если организацию всего этого хозяйства вы берёте на себя, тогда лично я бы был бы готов заплатить 100-150 долларов, при прочих равных условиях по железу.
Как-то так (-:
1 Load balanser
2 node.js (meteor.js)
3 MongoDB cluster
Всего — 6 сферических машинок. Предположим, проект только стартует и ему с головой хватит 5-10-долларового DO. Выходит 30-60 долларов/месяц.
Например, если организацию всего этого хозяйства вы берёте на себя, тогда лично я бы был бы готов заплатить 100-150 долларов, при прочих равных условиях по железу.
Как-то так (-:
У меня несколько странный вопрос:
Не могли бы вы открыть доступ к визуальному редактору уже сейчас?
К какой-нибудь статической, не привязанной ни к чему версии. И пусть даже всё, что можно будет от неё получить, это только «картинку».
Не могли бы вы открыть доступ к визуальному редактору уже сейчас?
К какой-нибудь статической, не привязанной ни к чему версии. И пусть даже всё, что можно будет от неё получить, это только «картинку».
А почему бы и нет? Думаю к понедельнику может получиться. Я вышлю приглашение.
Тоже бы хотелось получить приглашение в визуальный редактор.
И когда ± месяц / год ожидается релиз с рабочим функционалом?
И когда ± месяц / год ожидается релиз с рабочим функционалом?
Присоединяюсь, и как я понимаю вы без библиотек (svg.js, d3.js, рафаель?) работали с svg?
И мне, пожалуйста.
Кажется, это может стать идеальным инструментом для рисования подобных схем (главное, чтобы исходники хранились тектовыми файлами в гите и можно было видеть историю изменений).
Кажется, это может стать идеальным инструментом для рисования подобных схем (главное, чтобы исходники хранились тектовыми файлами в гите и можно было видеть историю изменений).
Получилось? :-)
Или надо было на сайте подписаться, чтобы приглашение получить?
Или надо было на сайте подписаться, чтобы приглашение получить?
Я тоже задолбался рисовать бекенды в gliffy, даже просто удобное набраасывание деплоймент схемы будет весьма полезно
Перечитал два раза и так и не понял что же вы предлагаете (посему все что дальше — возможно следствие неправильно истолкованной идеи, но уж извините, как написали так и понял). Комментарии поразили еще больше — такое чувство что это не хабр, а новостное агенство средней степени желтизны.
Если вы реально сталкивались с граблями при построении систем малой и средней степени сложности — как пришли к идее универсализации? В реальных, даже самых простых проектах деплой любого из серверов — это кастомный скрипт немалого размера…
Да, можно и нужно автоматизировать развертывание своей системы (есть даже должность такая — билд-инженер), но это не поддается шаблонизации, по определению! Сколько систем — столько и разных манипуляций с настройками, архитектур и стеков.
Несомненно, ваше решение хорошо подходит для развертывания ваших же серверов под ваши конкретные задачи, но как только к вам потянутся реальные юзеры со своими проблемами — все рассыпется.
Давайте уж графический построитель любого приложения — натянул на экран модуль обработки входящих соединений, 10 обработчиков на все случаи жизни, модуль логгирования (соединяем палочкой с сервером логов) — чего уж там… фейсбук-киллер готов!
P.S. Если вы предлагаете хостинг, настройку и сопровождение — так и пишите, зачем все это заворачивать в Visio-like картинку с клеточками? Совершенно непонятно…
Если вы реально сталкивались с граблями при построении систем малой и средней степени сложности — как пришли к идее универсализации? В реальных, даже самых простых проектах деплой любого из серверов — это кастомный скрипт немалого размера…
Да, можно и нужно автоматизировать развертывание своей системы (есть даже должность такая — билд-инженер), но это не поддается шаблонизации, по определению! Сколько систем — столько и разных манипуляций с настройками, архитектур и стеков.
Несомненно, ваше решение хорошо подходит для развертывания ваших же серверов под ваши конкретные задачи, но как только к вам потянутся реальные юзеры со своими проблемами — все рассыпется.
Давайте уж графический построитель любого приложения — натянул на экран модуль обработки входящих соединений, 10 обработчиков на все случаи жизни, модуль логгирования (соединяем палочкой с сервером логов) — чего уж там… фейсбук-киллер готов!
P.S. Если вы предлагаете хостинг, настройку и сопровождение — так и пишите, зачем все это заворачивать в Visio-like картинку с клеточками? Совершенно непонятно…
Согласен с вами что существуют системы в которых без напильника не обойтись, однако не все системы такие уж страшные. К примеру можно разобрать деплой системы из комментария выше. Всё просто есть балансер nginx, node.js, mongo.
Чем не простая реальная система?
Ну допустим вы первым делом, будете поднимать окружение для node.js, затем будете поднимать сервер с монгой. Неужели на этапе создания прототипа вы будете писать «кастомный скрипт немалого размера»? Вряд ли! На данном этапе вам надо быстро подготовить окружение для разработки, что бы начать работать.
Далее, когда всё готово к продакшн запуску, необходим тюнинг. Только и на этом этапе, что вы будете например править в конфигах nginx, или в node.js, когда всё и так работает? Никто не говорит что тюнинг не нужен — наоборот! Он даже необходим. Поэтому мы даём возможность настроить каждый элемент схемы. Каждый элемент схемы имеет свой, присущий ему набор конфигураций. Мы даже предусмотрели возможность подгружать конфиг файлы.
Может быть есть какие то специфические места, которые присущи проектам с которыми вы работаете, я бы с удовольствием учёл бы этим моменты при разработки системы.
Чем не простая реальная система?
Ну допустим вы первым делом, будете поднимать окружение для node.js, затем будете поднимать сервер с монгой. Неужели на этапе создания прототипа вы будете писать «кастомный скрипт немалого размера»? Вряд ли! На данном этапе вам надо быстро подготовить окружение для разработки, что бы начать работать.
Далее, когда всё готово к продакшн запуску, необходим тюнинг. Только и на этом этапе, что вы будете например править в конфигах nginx, или в node.js, когда всё и так работает? Никто не говорит что тюнинг не нужен — наоборот! Он даже необходим. Поэтому мы даём возможность настроить каждый элемент схемы. Каждый элемент схемы имеет свой, присущий ему набор конфигураций. Мы даже предусмотрели возможность подгружать конфиг файлы.
Может быть есть какие то специфические места, которые присущи проектам с которыми вы работаете, я бы с удовольствием учёл бы этим моменты при разработки системы.
Рассмотрим пример.
Для инициализации своих серверов я использую иерархию скриптов. Общие скрпиты, которые необходимо выполнять на всех нодах (это всякие мелочи и ньюансы типа вида командной строки, установка пакетов вроде htop, screens, zabbix-agent и т.п., тюнинг параметров ОС) и узко-специальные, для каждой конкретной ноды.
Оставим в стороне скрипт общего назначения (только он один тянет где-то на 200 строк), перейдем к узко-специальному.
Узел с реляционной БД. Скрипт инициализации занимает ~120 строк.
— Установка сервера БД (postgres) из репозитория
— Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
— Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
— Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
— Развертывание самой БД из SQL скриптов (3 разные схемы)
— Набивка базы данными из дампов
— Создание директорий, установка прав
— Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
— Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач
Ах да, все это я хочу чтобы стояло на ZFS с соотв. тюнингом под БД моего размера, при этом ОС я тоже хочу выбрать себе сам.
В каком месте ваше решение призвано упростить жизнь? Конечно, можно оставить лазейку для «выполнить кастомный скрипт какой угодно сложности», но это уже надувательство, друпальщина…
Кто вообще конечный пользователь вашего продукта? Админ\билд-инженер? Забудьте, вы никогда не перетащите эту категорию из командной строки в гуйню. Неопытный начинающий пользователь? Тоже не выстрелит — неопытный начинающий пользователь споткнется сразу после кружочка WAN и nginx (см. вашу первую картинку).
Для инициализации своих серверов я использую иерархию скриптов. Общие скрпиты, которые необходимо выполнять на всех нодах (это всякие мелочи и ньюансы типа вида командной строки, установка пакетов вроде htop, screens, zabbix-agent и т.п., тюнинг параметров ОС) и узко-специальные, для каждой конкретной ноды.
Оставим в стороне скрипт общего назначения (только он один тянет где-то на 200 строк), перейдем к узко-специальному.
Узел с реляционной БД. Скрипт инициализации занимает ~120 строк.
— Установка сервера БД (postgres) из репозитория
— Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
— Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
— Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
— Развертывание самой БД из SQL скриптов (3 разные схемы)
— Набивка базы данными из дампов
— Создание директорий, установка прав
— Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
— Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач
Ах да, все это я хочу чтобы стояло на ZFS с соотв. тюнингом под БД моего размера, при этом ОС я тоже хочу выбрать себе сам.
В каком месте ваше решение призвано упростить жизнь? Конечно, можно оставить лазейку для «выполнить кастомный скрипт какой угодно сложности», но это уже надувательство, друпальщина…
Кто вообще конечный пользователь вашего продукта? Админ\билд-инженер? Забудьте, вы никогда не перетащите эту категорию из командной строки в гуйню. Неопытный начинающий пользователь? Тоже не выстрелит — неопытный начинающий пользователь споткнется сразу после кружочка WAN и nginx (см. вашу первую картинку).
— Установка сервера БД (postgres) из репозитория
— Создание пользователя-админа БД, директорий для БД и индекса (для последующего выноса на отдельный диск)
— Тюнинг /etc/sysctl.conf, /boot/loader.conf специально для данной БД
— Тюнинг postgresql.conf и pg_hba.conf специально для данной БД
— Развертывание самой БД из SQL скриптов (3 разные схемы)
— Набивка базы данными из дампов
— Создание директорий, установка прав
— Копирование на узел и занесение в крон выполнения 8 скриптов по расписанию
— Установка доп. специфич. пакетов (pear-MDB2_Driver_pgsql, php5-pgsql) для выполнения узко-специфич. задач
Ведь можно скрипты тюнинга прикрутить к элементу? Я же отписал выше —
Мы даже предусмотрели возможность подгружать конфиг файлы.Для дампов есть специальный раздел настроек сервисов баз данных.
Я не говорю что мы не предусмотрели все нюансы. Эта статья как раз и написана для того что бы их собрать и учесть. Однако, наверное вы упустили одну маленькую деталь: Вы не собираете схему из серверов — вы собираете схему из сервисов, каждый из которых может уникально настраиваться. И наша задача сделать полезный инструмент, которым может пользоваться любой — от разработчика до администратора, до ассистента тех поддержки и мониторинга.
Поэтому и ЗБТ. Был бы рад получить ваши пожелания и рекомендации, я думаю помогли бы учесть некоторые нюансы.
PS
Однако я бы не держал php сервис на одной машине с реляционной бд… судя по вашему скрипту… Потому что как то странно, то тюним на уровне ОС и БД, то саму БД вместе с аппликейшеном держим. Хотя справедливости ради я не знаю что они выполняют. Но выглядит странно.
Вообщем стало понятно: вы покусились задвинуть святое — ком. строку! Что ж, удачи вам в этом неблагодарном (и думается — бесперспективном) деле.
Ну почему же сразу задвинуть. Мы и сами используем терминал. Я например программирую исключительно в vi. Да и даже в tmux powerline настраивал, что бы spotify треки мне там рисовал. Это прикольно, но извините, деплоить и обновлять с десяток серверов, уже поднадоело.
А что вам мешает написать скрипт, который все это будет делать за вас, почему возникла необходимость в графическом редакторе?
Вроде бы черным по белому написано:
Еще не опробовав сервис, вы уже начинаете пророчить его крах.
Вы пишете, что у вас есть скрипт, который все делает за вас, хотя в puppet\chef эти все решения уже есть и это является более взрослым решением, нежели ваши скрипты.
Возможно, что этот зачаток сможет перерасти в более зрелое решение, для создания инфраструктуры у облачных провайдеров.
Живя в таком мире довольно большое количество времени, мы подумали — «ну мы же разработчики, давай-те сделаем с этим что-то». Прикинув проблемы, сопровождающие нас на каждом этапе создания и развития проекта — выписали их на отдельной страничке и превратили их в фичи будущего сервиса.
Еще не опробовав сервис, вы уже начинаете пророчить его крах.
Вы пишете, что у вас есть скрипт, который все делает за вас, хотя в puppet\chef эти все решения уже есть и это является более взрослым решением, нежели ваши скрипты.
Возможно, что этот зачаток сможет перерасти в более зрелое решение, для создания инфраструктуры у облачных провайдеров.
puppet — типичный overkill. Возможно, кто-то таки потратил время и нервы на его изучение и остался им доволен… И, на секундочку, — все «блекджеки и шлюхи» puppet-а — именно в мощи мета-языка, которым описываются конфиги, GUI там постольку поскольку…
Будет ли свой мета-язык, сравнимый по мощи с puppet-овским у данного сервиса? Тогда с него и надо было начинать. Пока что подход, выбранный авторами, — дать визуальную картинку на первый план и комментарии типа «Можно использовать свои сервера, а можно разворачивать на наших. Второй вариант предпочтительнее, снимает кучу головняка.» — отпугнет большинство админов и билд-инженеров.
Будет ли свой мета-язык, сравнимый по мощи с puppet-овским у данного сервиса? Тогда с него и надо было начинать. Пока что подход, выбранный авторами, — дать визуальную картинку на первый план и комментарии типа «Можно использовать свои сервера, а можно разворачивать на наших. Второй вариант предпочтительнее, снимает кучу головняка.» — отпугнет большинство админов и билд-инженеров.
Судя вашей логике, в принципе использование виртуальных машин так же обречено на провал, как и облачные сервисы.
Ведь логика всё та же — упростить жизнь и сэкономить время. А по вашим словам получается, что самым идеальным вариантом является построение своего хостинга, саморучно устанавливая сервера в стойки. Можно примеров привести до бесконечности. Просто помню аналогичные холивары на тему облачных сервисов, однако живут и процветают. И более того скажу, есть отличный пример — сервис heroku. Там система push-to-deploy, кстати, довольно распространённая в последнее время. Так что я бы не был бы столь категоричен.
Ведь логика всё та же — упростить жизнь и сэкономить время. А по вашим словам получается, что самым идеальным вариантом является построение своего хостинга, саморучно устанавливая сервера в стойки. Можно примеров привести до бесконечности. Просто помню аналогичные холивары на тему облачных сервисов, однако живут и процветают. И более того скажу, есть отличный пример — сервис heroku. Там система push-to-deploy, кстати, довольно распространённая в последнее время. Так что я бы не был бы столь категоричен.
Да тогда просто под каждую конфигурацию писать скрипт придётся. Занимались и этим. При этом всё равно нет никакой визуализации. Вот у меня было в проекте 20+ серверов. Была вики с их списком и с перечнем что и как было на них установлено. Когда проект растёт, а живой проект всегда растёт, приходилось каждый раз при внедрении нового сервиса вспоминать и рисовать в голове схему взаимодействия данных. А так всё наглядно и сразу воспринимаешь весь backend. Так же и средства мониторинга сейчас оставляют желать лучшего, не в плане техническом, а в плане визуализации.
Мы смотрим фильмы с интерфейсами будущего, а сами при этом не понимаем зачем нам визуализация данных. Я предлагаю лучше создавать эти интерфейсы. Пускай методом проб и ошибок, но хоть как то развивать инструменты разработчиков, ведь это помогает быстрее создавать более лучшие продукты.
Можно привести хорошую аналогию между vi и intellij Idea. Например я не считаю что программировать необходимо исключительно в vi. Есть проекты, в которых хорошая IDE заметно ускорит процесс разработки и позволит избежать ошибок. Иногда и мне приходится так делать, хотя в программировать стараюсь в vi. Так же и в случае проекта.
Мы смотрим фильмы с интерфейсами будущего, а сами при этом не понимаем зачем нам визуализация данных. Я предлагаю лучше создавать эти интерфейсы. Пускай методом проб и ошибок, но хоть как то развивать инструменты разработчиков, ведь это помогает быстрее создавать более лучшие продукты.
Можно привести хорошую аналогию между vi и intellij Idea. Например я не считаю что программировать необходимо исключительно в vi. Есть проекты, в которых хорошая IDE заметно ускорит процесс разработки и позволит избежать ошибок. Иногда и мне приходится так делать, хотя в программировать стараюсь в vi. Так же и в случае проекта.
Ну поймите же, что деплоймент проектов средней сложности сопоставим по сложности с написанием кода приложений (по сути им и является). До сих пор все попытки визуализировать создание кода с помощью визуальных представлений с треском проваливались. В фильмах конечно все красиво, но на то они и фильмы, что в реальности код пишут руками, а админят из ком. строки. Вашу идею можно сравнить с 3д-файл менеджерами — все баловались, да красиво, да как в фильме, но нафиг никому не нужно. Нарисовать связи можно и в Open Visio каком-нибудь, не ради же красивой картинки вы задумали весь проект?
Вы пробовали использовать kickstart?
Про puppet тоже, возможно, что-то слышали.
Вручную/скриптом я бы делал тут только одно: заливал нуль-дамп в базу.
Про puppet тоже, возможно, что-то слышали.
Вручную/скриптом я бы делал тут только одно: заливал нуль-дамп в базу.
>Несомненно, ваше решение хорошо подходит для развертывания ваших же серверов под ваши конкретные задачи, но как только к вам потянутся реальные юзеры со своими проблемами — все рассыпется.
Может быть поэтому открывают доступ к ЗБТ?
Может быть поэтому открывают доступ к ЗБТ?
комментарий удалён
Лично мне это чем-то напомнило решения типа Heroku. У них есть входная точка, потом идет роутер, который посылает запросы к worker'ам, а ими может быть все, что угодно — nodejs, go, ruby, python.
К worker'ам же подключаются различные плагины в виде БД, поиска (elastichsearch), аналитики, отправки писем и т.д., сами эти сервисы работают в «облаках».
Причем так как это все работает в основном в Amazon датацентрах (и Heroku, и плагины), то связь между системами идет по локальной гигабитной сети и задержки минимальны.
К worker'ам же подключаются различные плагины в виде БД, поиска (elastichsearch), аналитики, отправки писем и т.д., сами эти сервисы работают в «облаках».
Причем так как это все работает в основном в Amazon датацентрах (и Heroku, и плагины), то связь между системами идет по локальной гигабитной сети и задержки минимальны.
Ставлю плюс. Не за само решение, за хорошую подачу информации. Спасибо.
пообещайте масштабирование meteor.js приложений — получите хороший PR
Спасибо за совет. В принципе не вижу проблем в техническом плане.
Там одна проблема — sticky sessions.
Именно поэтому я в своём сферическом примере и привёл meteor.js (-:
Именно поэтому я в своём сферическом примере и привёл meteor.js (-:
А что означает эта загадочная надпись после регистрации?
Petrogradsky district.
St.Petersburg, LED 196626
Было бы интересно узнать состав команды Lastbackend и как развивалась идея и продукт. Что-нибудь типа… сидели мы в кафе и тут упало яблоко. А дальше на салфетках рисовали, а возможно не рисовали.
Согласитесь, не каждый день рассказывают о таких идеях.
Согласитесь, не каждый день рассказывают о таких идеях.
а к альфе доступ можно както получить?
Странно но у меня в фаерфоксе диаграмма на вашей главной обрезана
Думаю, даже удобная рисовалка диаграмм конфигураций с заведением спецификаций каждой ноды и возможностью экспорта все этого допустим в pdf или html была бы полезна. Как-нибудь обязательно попробую ваш сервис
Правильно ли я понимаю, что эта штука предназначена для веб-разработчиков, которые хотят обойтись без инженерного отдела для мелких и средних проектов?
Не только. Вот взять к примеру пинтерест. Там есть серверная часть и она довольно большая, с огромным количеством узлов, шедулеров, баз данных и всяких прочих воркеров. Там очень классная система подъема серверов на амазоне, написно тонны скриптов и есть большая вики со схемкой как это всё работает. Так представим на минуту, что ребята берут нашу систему, и тогда у них есть всё так же схема, только живая, из под которой можно управлять всем бекендом и анализировать информацию, мониторить систему.
Я считаю что данная система может найти применение как для инди разработчиков, так и для крупных проектов.
Я считаю что данная система может найти применение как для инди разработчиков, так и для крупных проектов.
Задам вопрос тут по nodejs и Mongodb stackoverflow.com/questions/21269345/handle-lost-connection-to-mongo-db-from-nodejs на который так и нет ответа. Если будет отдельная статья напишу вопрос комментарием там.
Круто! Мне кажется, что даже сам по себе такой редактор с возможностью экспорта/импорта данных в xml/json/yaml имел бы успех)
Но вы пошли ещё дальше) Желаю вам не сдаваться и утереть нос всем, кто говорит, что то, что вы делаете — невозможно)
Делать невозможные вещи — это самое приятное в работе)
Но вы пошли ещё дальше) Желаю вам не сдаваться и утереть нос всем, кто говорит, что то, что вы делаете — невозможно)
Делать невозможные вещи — это самое приятное в работе)
Уже середина июля, а новых фишек, запланированных на июнь пока нет. Проект жив?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Backend без проблем. Чудо или будущее?