Да, интересный момент. Но это больше про культуру общения. Тут уже кому, как привычнее. Наверное, если сказать что-то типа "Извините, вынужден вас перебить..." это не обидно. Если люди особо культурные, будут терпеливо ждать, пока человек допишет.
То есть приложение не диктует правила в общении, оно делает его максимально приближенным к реальному.
Порой перебить - это даже хорошо. Человек может долго что-то формулировать, а собеседник может снять весь вопрос за секунду, увидев о чем идет речь. Все это ускоряет общение, как в реальной жизни. Никому не хочется тратить силы на написание сообщение, если оно не имеет смысла, например.
Если отбросить стеснение, это довольно сильно ускоряет общение, потому что собеседники непрерывно вовлечены в разговор. Можно уже начать обдумывать ответ, пока второй человек еще пишет вопрос. Все, как при реальном общении, где у нас тоже нет условного буфера и кнопки "Отправить"
Prosemirror - действительно мощная библиотека для создания WYSIWYG редакторов. Мы до этого использовали Quill.js и другие редакторы в разных проектах. Но именно Prosemirror отличается высокой стабильностью и возможностью легкой реализации любого функционала вплоть до collaborative editing.
На базе Prosemirror мы с автором статьи создали приложение для управления задачами и общения в реальном времени. Пользователи видят в реальном времени все что пишут в чате. То есть в принципе отсутствует такое действие, как “отправка сообщения”. Все происходит вживую, как при обычном разговоре.
Также Prosemirror позволил нам довольно легко реализовать совместное редактирование в реальном времени в первых сообщениях лент, включая анимацию курсоров. Если кому интересно будет пощупать этот функционал, ссылка на проект есть у меня в профиле
Да, во многом могу согласиться. Чтобы понять ценность для англоязычной аудитории надо выкинуть все, что ей не интересно. То есть переводы, посты из блогов российских компаний, посвященные больше услугам этих компаний. А оставшееся небольшое количество хороших статей должно быть написано на хорошем английском — думаю, авторов, которые захотят писать их на английском и смогут делать это хорошо, будет не так уж много. Велика вероятность, что эти авторы предпочтут публиковать статьи на более известных иностранных площадках, том же Medium, где публикуется огромное количество разработчиков со всего мира.
Но это все, если не принимать во внимание то, что на глобальный Хабр могут придти иностранные авторы. Только при этом условии, мне кажется, будет успех. Однако не думаю, что иностранные авторы быстро перекочуют к нам с Medium и тому подобных ресурсов. Но шанс есть. Преимущество Хабра в его IT-ориентированности.
PS. Сам недавно задумался о том, что надо писать статьи на английском тоже. РКН — хороший мотиватор.
Не сравнивал, т.к. IP на Амазоне стал недоступен. Но по ощущениям работа сайта нисколько не замедлилась, может даже ускорилась. Возможно, там есть кэширование — я не изучал глубоко этот сервис. Вообще он для предотвращения DDOS-атак предлагается.
Да, кстати, забыл написать, этот вариант с подключением CloudFront тоже рассматривал. Но в итоге решил, что перейти на IP в Люксембурге от не столь крупной компании, будет надежнее. Вряд ли так карты лягут, что Телеграм тоже начнет её IP использовать. А точки доступности CloudFront Амазона, как я понимаю, тоже могут попадать в блокировки. В общем отдал предпочтение IP за пределами России и не от Амазона.
Мы — маленькая компания и судиться с РКН не осилим. Я лишь искренне надеюсь, что без большого количества исков и последствий все это для нашего государства в лице РКН не закончится.
Было бы неплохо еще в этом посте собрать варианты действий, если ваш ресурс попадает под блокировку. Расскажу про свой опыт. У меня один обычный сайт на EC2 попал под блокировку (его elastic ip оказался в заблокированной подсети). Он открывался через friGate, но был недоступен напрямую.
Вначале я попробовал просто получить новый elastic ip и перевести домен на новый IP. Но оказалось, все не так просто — Amazon выдает адреса обычно близкие друг к другу и велика вероятность, что они все будут в заблокированных подсетях.
Мне пришли в голову 2 варианта:
1) Получить elactic ip в другом удаленном регионе и перевести instance туда. Но это ухудшает работу ресурса, так как он рассчитан на пользователей из России, а CDN не используется. И это требует большей возни: нужно выключать instance, снимать с него образ и разворачивать его в другом регионе. Поэтому я пошел по второму варианту.
2) Купить reverse proxy и перевести домен сайта на него. Я купил за 10 долларов reverse proxy в Люксембурге (x4b.net), в качестве бекенда для прокси прописал свой elastic ip на Amazon и буквально через 5 минут сайт вновь заработал, как ни в чем не бывало. Очень надеюсь, что через некоторое время блокировки снимутся и можно будет отказаться от reverse proxy!
На очень многих ресурсах наблюдаю проблему с частичной недоступностью картинок, файлов и прочего. Многие сайты из-за этого очень долго грузятся, какие-то становятся в полурабочем состоянии. Вот например, эти иконки на bitbucket.com загружаются из S3.
Спустя какое-то время, видимо, блокировка снимается с части адресов и ставится на новые адреса.
Но в целом получается, чтобы нормально пользоваться интернетом в России теперь нужно пользоваться VPN. Забавным выглядит на фоне этого высказывания РКН, что блокировка Telegram не нарушила работу других сайтов. Наверное, мы с ними пользуемся разными Интернетами.
РКН напоминает чуму или проказу. Она поражает несчастного, в данном случае Телеграм, и дальше куда бы он ни пошел, вымирают целые деревни. И этого несчастного будут дальше палками гнать ото всюду, чтобы он не принес заразу в деревню.
Пишу сугубо свое мнение, могу ошибаться. Я считаю, что эти проекты — следствие того, что AWS вовремя не создал адекватные средства для удобной разработки бессерверных приложений. Люди не хотели ждать, и это понятно, поэтому появились эти проекты. По своей сути, это «костыли» или временные решения. Автор плагина serverless-offline уже объявил о своем нежелании продолжать проект и просит кого-то его подхватить. В общем будущее за SAM и sam-local, именно на этих технологиях стоит выстраивать процесс разработки в долгосрочной перспективе.
1. Насчет Vue.js — согласен, отличный фреймворк. Но вы смотрите на вопрос, как программист. Да, Vue.js может здорово повысить продуктивность написания кода для некоторых типов приложений. Но сколько программистов знают Vue.js и сколько знают jQuery? На сколько больше нужно платить программистам Vue.js? В общем это не столь однозначный вопрос. И я больше склоняюсь к тому, что нам не нужен фреймворк, если взвешивать все за и против и оценивать пользу фреймворка для конкретного типа приложений. Наши приложения — это ERP-системы, которые состоят в основном из форм и таблиц.
2. По-моему с этим все ОК, написал выше.
3. Мы вовсе не делаем конкурента Serverless framework. Скорее можно сказать, что Serverless framework и sam-local конкуренты, но никак не AB-ERP. А название AB-ERP выбрано из-за того, что наша заготовка в первую очередь ориентирована на создание ERP-систем и тому подобных приложений.
Google Firebase — это конкурент AWS. Не берусь сравнивать их с AWS, с Firebase я не работал. Много лет назад «подсел» на AWS и с тех пор не перестаю восхищаться ими, это целая вселенная :) Мне кажется, в целом они опережают своих конкурентов на годы. Об этом красноречиво говорят шильдики «бета» напротив многих сервисов Firebase.
Переменные, объявленные вне вызова функции handler, при повторных вызовах обычно не инициализируются повторно. То есть соединение с БД не будет каждый раз устанавливаться заново, если функция вызывается достаточно часто. Lambda сохраняет контейнер функции в «горячем» состоянии. Вот интересный пост на эту тему: https://www.jeremydaly.com/reuse-database-connections-aws-lambda/.
Разворачивать инфраструктуру я предполагаю командами aws cli на основе шаблона CloudFormation + bash код. Подобный скрипт я приводил в своей предыдущей статье про то, как мы делаем AB-DOC.
Насчет zappa и WSGI — не знал. Почитал сейчас. Во-первых, я никогда не программировал на Python (может зря). Во-вторых, мне априори не нравятся сторонние фреймворки, не поддерживаемые вендором. Они могут быстро становится ненужными и лишаться поддержки, если сам вендор предложит полноценное решение. А SAM и sam-local похоже всерьез и надолго.
Последнее предложение вашего комментария я не в силах до конца понять.
Понравилась статья, но тема не до конца раскрыта. Есть ощущение, что подробно описана проблема, но решение не дано.
Быть всегда "хорошим" не стоит, быть "плохим" - тоже. Как же найти золотую середину?
Ну тут да, надо быть аккуратнее, конечно, чем в традиционном чате. Но также в гугл докс, например, при совместной работе с документом.
Да, интересный момент. Но это больше про культуру общения. Тут уже кому, как привычнее. Наверное, если сказать что-то типа "Извините, вынужден вас перебить..." это не обидно. Если люди особо культурные, будут терпеливо ждать, пока человек допишет.
То есть приложение не диктует правила в общении, оно делает его максимально приближенным к реальному.
Порой перебить - это даже хорошо. Человек может долго что-то формулировать, а собеседник может снять весь вопрос за секунду, увидев о чем идет речь. Все это ускоряет общение, как в реальной жизни. Никому не хочется тратить силы на написание сообщение, если оно не имеет смысла, например.
Если отбросить стеснение, это довольно сильно ускоряет общение, потому что собеседники непрерывно вовлечены в разговор. Можно уже начать обдумывать ответ, пока второй человек еще пишет вопрос. Все, как при реальном общении, где у нас тоже нет условного буфера и кнопки "Отправить"
Но это все, если не принимать во внимание то, что на глобальный Хабр могут придти иностранные авторы. Только при этом условии, мне кажется, будет успех. Однако не думаю, что иностранные авторы быстро перекочуют к нам с Medium и тому подобных ресурсов. Но шанс есть. Преимущество Хабра в его IT-ориентированности.
PS. Сам недавно задумался о том, что надо писать статьи на английском тоже. РКН — хороший мотиватор.
Вначале я попробовал просто получить новый elastic ip и перевести домен на новый IP. Но оказалось, все не так просто — Amazon выдает адреса обычно близкие друг к другу и велика вероятность, что они все будут в заблокированных подсетях.
Мне пришли в голову 2 варианта:
1) Получить elactic ip в другом удаленном регионе и перевести instance туда. Но это ухудшает работу ресурса, так как он рассчитан на пользователей из России, а CDN не используется. И это требует большей возни: нужно выключать instance, снимать с него образ и разворачивать его в другом регионе. Поэтому я пошел по второму варианту.
2) Купить reverse proxy и перевести домен сайта на него. Я купил за 10 долларов reverse proxy в Люксембурге (x4b.net), в качестве бекенда для прокси прописал свой elastic ip на Amazon и буквально через 5 минут сайт вновь заработал, как ни в чем не бывало. Очень надеюсь, что через некоторое время блокировки снимутся и можно будет отказаться от reverse proxy!
Спустя какое-то время, видимо, блокировка снимается с части адресов и ставится на новые адреса.
Но в целом получается, чтобы нормально пользоваться интернетом в России теперь нужно пользоваться VPN. Забавным выглядит на фоне этого высказывания РКН, что блокировка Telegram не нарушила работу других сайтов. Наверное, мы с ними пользуемся разными Интернетами.
Непонятно, что делать, ну сменю я ему elastic ip, но надолго ли это поможет? Если РКН хаотично рубит все подряд…
Упс. Промахнулся. Отвечал zaikin-andrew.
2. По-моему с этим все ОК, написал выше.
3. Мы вовсе не делаем конкурента Serverless framework. Скорее можно сказать, что Serverless framework и sam-local конкуренты, но никак не AB-ERP. А название AB-ERP выбрано из-за того, что наша заготовка в первую очередь ориентирована на создание ERP-систем и тому подобных приложений.
Google Firebase — это конкурент AWS. Не берусь сравнивать их с AWS, с Firebase я не работал. Много лет назад «подсел» на AWS и с тех пор не перестаю восхищаться ими, это целая вселенная :) Мне кажется, в целом они опережают своих конкурентов на годы. Об этом красноречиво говорят шильдики «бета» напротив многих сервисов Firebase.
Разворачивать инфраструктуру я предполагаю командами aws cli на основе шаблона CloudFormation + bash код. Подобный скрипт я приводил в своей предыдущей статье про то, как мы делаем AB-DOC.
Насчет zappa и WSGI — не знал. Почитал сейчас. Во-первых, я никогда не программировал на Python (может зря). Во-вторых, мне априори не нравятся сторонние фреймворки, не поддерживаемые вендором. Они могут быстро становится ненужными и лишаться поддержки, если сам вендор предложит полноценное решение. А SAM и sam-local похоже всерьез и надолго.
Последнее предложение вашего комментария я не в силах до конца понять.