Илья Плотников ilyaplot

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

Оказалось, что все настолько просто, что реализация задумки заняла у меня всего минуту.

В сентябре 2009 года была опубликована статья об уязвимости, связанной с системой контроля версий subversion, позволяющей скачать исходники сайтов, использующих SVN. Периодически от нечего делать мой мозг хотел, что бы я написал граббер и проверил актуальность данной угрозы на текущий момент, но было как-то лень. Однако, мне не давал покоя комментарий хабраюзера Semenov



Понятно, что каждый школьник уже попробовал скачать %sitename% через .svn, потому от этой идеи я отказался сразу, зато попробовать git clone %sitename%/.git/ руки чесались.

Цели, задачи, оправдания безумства.

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

Вопросы, на которые я решил получить ответ «да»

• Можно ли создать Telegram бота в Google Script?
• Можно ли бесплатно использовать API Google Translate без регистрации и SMS?
• Можно ли сделать онлайн инструмент без использования хостинга?

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

Ащепятки

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

Почему мы все здесь собрались?

Ни для кого не секрет, то что контент Хабрахабра и Geektimes создается его же пользователями. Понятно, что разные авторы создают контент разного качества, а иногда даже бессовестно копирует чужой труд. Для регулирования контента используется карма и голоса за посты, и это отлично работает, но нет никаких инструментов для возможности внести свой вклад в чужую статью.

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



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

 

Обычно программисты используют технологии по прямому назначению, но я решил провести эксперимент и попробовать использовать сервер memcached как масштабируемое временное key=value хранилище.
Memcached предназначен для простого кэширования статических данных, потому в нем не предусмотрена система избежания коллизий.

Запись данных

Стандартная ситуация

Предположим, что наше PHP приложение работает на одном сервере, а memcached работает на удаленной машине. Мы без проблем сможем читать и писать в одну и ту же ячейку, потому как приложение не WEB, так что процесс один. Из-за линейности процесса, ему не удастся одновременно записывать разные данные в одну и ту же ячейку.

Два и более процесса

Сегодня нам понадобилось разделить приложение на два сервера и начались проблемы. Возникли коллизии при записи в memcache. Выяснилось, что в 80% случаев приложения пытаются одновременно записать свои данные в одну ячейку. Идеальным решением было бы использование shared memory, но она не масштабируется в отличие о Memcached. В связи с большим объемом кода и предполагаемым временем на переписывание приложений, было принято решение добавить костыль.