Данная статья была написана в виде поста для Хабра в большей части из-за того, что вокруг вопроса онлайн-касс для интернет-сайтов возник настоящий информационный вакуум. С одной стороны, в сети полно статей на тему онлайн-касс, с другой — информации непосредственно о решениях для веб-сайтов не очень много, особенно технической. Только слова, что «надо срочно» и «будут штрафовать». Нам этот квест показался достаточно интересным и запутанным, если кому поможет — будем рады.

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

Если вы продаете ПО, то наверняка при виде бюджетов больших корпораций задумывались, как бы и вам откусить кусочек от этого пирога. Лично мы в Web-payment.ru, проекте о платежных системах, постоянно ищем способы заполучить в партнеры крупные платежные системы или сервисы на рекламные услуги, разработку, или даже помощь в ведении блога на Хабре. В этой статье-переводе как раз пойдет речь о том, как работать с крупной рыбой. Сразу хотел бы предупредить, что наши реалии отличаются от западных, которые описываются в статье, но в чем-то они пересекаются, так что почитать интересно.

Многие задаются вопросом о продаже ПО офигенно большим организациям. Работать с такими крутыми компаниями в установленном вами ценовом диапазоне крайне непросто, так как любые величины меньше 500$ для них выглядят как ошибка в округлении. В то же время, наличие пары таких клиентов дарует вам социальную значимость, которая позволяет вам продавать как другим таким же гигантам, так и более мелким клиентам. Получив IBM в качестве клиента, вы ничего не потеряете. Ну а если при этом в самом IBM никого не уволили за выбор вас в качестве поставщика, значит, и вы вполне подходите для большой игры.

Доброго времени суток хабровчане, в этом посте я попытаюсь наглядно объяснить про установку Nvidia CUDA toolkit на Ubuntu 12.04 x86_64. Начну с того, что меня сподвигло написать данный пост. Совсем недавно мне потребовалось установить Nvidia CUDA toolkit себе на домашний компьютер. Почитав добрую часть мануалов по установке, при чем не только на русском языке, я решил, что установить пакет от Nvidia будет проще пареной репы, но вот тут я ошибался. Большинство мануалов заточено под старые версии убунты, кроме того, зачастую в них отсутствуют некие изюминки установки, что рано или поздно приводит читателя в тупик. И так кто заинтересовался — милости прошу под кат…

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

Приятного чтения!

Доброго времени суток!

Несколько дней назад на одном из своих сайтов заметил подозрительную активность, вызванную перебором паролей. Произошло это как раз тогда, когда в сеть попали файлы с несколькими миллионами почтовых ящиков и паролей к ним. После бана в iptables нескольких адресов злоумышленники начали подбирать пароли с бОльшего количества адресов и вручную банить их уже стало неудобно. Как была решена эта проблема расскажу под катом.

В моем случае, в качестве frontend сервера, стоит nginx и формат access-лога имеет вид:

log_format main '$remote_addr — $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';

Что на выходе дает что-то вроде такой строки:

188.142.8.61 — - [14/Sep/2014:22:51:03 +0400] «www.mysite.ru» «GET / HTTP/1.1» 200 519 «6wwro6rq35muk.ru» «Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» "-" -> 0.003

1. tail -f /var/log/nginx/nginx.access.log | cut -d ' ' -f 1 | logtop

Позволяет получить общую картину: распределение уникальных IP, с которых идут запросы, кол-во запросов с одного IP и т.д.
Самое ценное — что все это работает в режиме реального времени и можно мониторить ситуацию, внося какие-либо изменения в конфигурацию (например просто забанить ТОП 20 самых активных IP через iptables или временно ограничить географию запросов в nginx через GeoIP http://nginx.org/ru/docs/http/ngx_http_geoip_module.html).

В этой статье я хочу поделиться почти 10-летним опытом использования Linux на домашнем компьютере. За это время я провел много экспериментов над ядром, испробовал различные конфигурации для разных применений и теперь хочу все это систематизировать в длинный пост с рекомендациями как выжать из linux максимум и добиться отличной производительности, без необходимости покупать мощное железо.

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

Хоть я и пообещал, что после прочтения этой статьи, можно будет играть в Metro 2033 на калькуляторе (шутка, такого не будет), все же она начнется с рекомендации купить кое-что из железа, если у вас этого еще нет.

Так уж вышло, что живем мы хоть и в продвинутой всякими технологиями стране, но стабильность интернет соединения для городов которые в дали от столицы это редкое явление. Долго выбирал всевозможные сервисы для профессионального мониторинга доступности оборудования в сети. У одних есть проверка только 80 порта веб-сервера, у других возможно проверить ключевое слово на странице, отправлять GET или POST запросы. Нашел сервис лучше других, есть там возможность проверить доступность ssh, но оплата зависит от количества запросов за определенный промежуток времени и естественно количество оборудования которое необходимо мониторить.

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

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

Python — красивый и местами загадочный язык. И даже зная его весьма неплохо, рано или поздно находишь для себя нечто такое, что раньше не использовал. Этот пост отражает некоторые детали языка, на которые многие не обращают внимание. Сразу скажу: многие примеры являются непрактичными, но, оттого, не менее интересными. Так же, многие примеры демонстрируют unpythonic стиль, но я и не претендую на новые стандарты — я просто хочу показать, что можно делать вот так.

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

Сегодня мы познакомимся с основной и самой многочисленной группой инструментов — событийными профайлерами.

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

Этот текст был задуман как попытка структурировать основные принципы успешной технической поддержки и общения в целом. Под «успешной» в данном контексте подразумевается положительная реакция непосредственно клиента на качество сервиса, т.е. его конкретное субъективное мнение по итогам обращения в техподдержку.

Немного об авторе: никакого психологического образования не получал, курсов общения с клиентами не проходил, так что все выводы основываются исключительно на личном опыте. Я начал работать в технической поддержке более 8 лет назад, в компании Acronis, тогда еще совсем небольшой, а штат техподдержки не превышал 10-15 человек. Сегодня в техподдержке участвует более 250 человек, поддерживая клиентов на девяти языках мира. Со временем я прошел все этапы — от работы в небольшом коллективе с практически нулевым уровнем личной ответственности до контроля и взаимодействия в большой инфраструктуре, включающей автоматический сбор статистики по каждому сотруднику для замеров его личного KPI (key performance indicators).

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

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

Не претендуя на библию или «настольную статью программиста» я хочу поделиться полезными находками в моей любимой IDE, не скатываясь в тупую копипасту мануалов и скучных списков хоткеев, только то, что я сам использую постоянно и над чем удивляются коллеги: «о! а так можно?»

Как то поздним вечерком мне пришла мысль изучить Backbone.js и привязать его к уже написанному на jQuery сервису. Сервис уже серьёзно расширился и меня достало это нагромождение обработчиков кликов, запросов и логики. Поэтому, я как усердный школьник полез в официальную документацию. Но либо я тупой, либо мой английский меня подкачал, либо то и другое вместе, но я не черта не понял. Я прочитал уже второй раз, внимательно, и для особо одарённых мест использовал google translate. Прочитал также и пример ToDo List. Всё показалось понятно, ровно до той поры пока я не стал писать. После чего я взял всё что нашел по этой библиотеке, как на английском так и переводы. Прочтя кипу документации я решил, что сейчас вроде всё понял. Я напрягся, но… Не вышел каменный цветок у мастера Данилы, т.е. вышло, но это явно был не цветок, и камень как то неправильно пах. Тогда, как прилежный ученик, я решил написать «Hello, KittyWorld» с нуля. Попутно комментируя и сохраняя шаги в hg, у меня получилось введение в backbone.js framework для таких как я, особо одарённых.

PHP всегда был простым, процедурным языком программирования, черпавшим свое вдохновение из C и Perl. В PHP 5 появилась правильная объектная модель, но о ней вы уже все знаете. А вот в PHP 5.3 появились замыкания (closure), которые были серьезно улучшены в версии 5.4 (подсказка: $this теперь доступен по умолчанию).

Читайте UPD7, Adobe разместила официальный ответ в своем блоге.

Акция невиданной щедрости от Adobe. Они решили раздать хоть и устаревший, но все же полный Creative Suite второй версии. Доступны версии как под Mac (PowerPC) так и под Windows.

В комплекте:

• Creative Suite 2
• Acrobat 3D 1.0 for Windows
• Acrobat Standard 7.0
• Acrobat Pro 8.0
• Audition 3.0
• GoLive CS2
• Illustrator CS2
• InCopy CS2
• InDesign CS2
• Photoshop CS2
• Photoshop Elements 4.0/5.0
• Adobe Premiere Pro 2.0

Спешите, количество скорее всего ограничено. Получить можно тут. Для получения необходима регистрация.


Скачать можно тут

UPD: Сайт слег, ключи одни и те же для всех. Под катом ключи и ссылки на софт. А так же сообщение от одного из разработчиков, говорящее что данные ключи и установщики могут использоваться только теми у кого уже есть купленная лицензия на CS2.

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

Я потратил несколько месяцев на борьбу с глюками Git-svn и обдумывание разных вариантов, прежде чем пришёл к этому методу организации рабочего процесса с сайтом — простому, гибкому и удобному в работе.

Основные преимущества:

• Делая push из удалённой копии мы автоматически обновляем live-копию сайта
• Правки файлов на сервере не будут разрушать историю коммитов
• Простота, не нужны особые правила выполнения коммитов
• Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

Многие из нас ежедневно используют в работе распределенные системы управления версиями, самыми популярными из которых сейчас безусловно являются Git и Mercurial. Для большей гибкости в работе исходные коды для проектов под контролем таких систем зачастую хранятся не локально, а на закрытых серверах компаний или в облачных сервисах наподобие Github или Bitbucket. Такие сервисы предоставляют разработчикам ПО, дизайнерам, писателям и людям других профессий, в чьи обязанности входит создание контента при помощи компьютеров, совместно работать над своими задачами, получать доступ к общим вики и планировщику задач и изучать продукты труда других пользователей, открытые для просмотра в публичных репозиториях.

Разные облачные сервисы по-разному подходят к вопросу оплаты за свои услуги. Так, наверное самый популярный на данный момент сервис «социального кодинга» GitHub разрешает бесплатно работать над любым количеством открытых проектов, но работа с закрытыми репозиториями возможна только для платных аккаунтов. Сервис BitBucket от известного австралийского поставщика систем совместной разработки Atlassian пока популярен не так, но его политика в плане привлечения новых клиентов более гибкая. В BitBucket вы можете бесплатно создавать любое количество закрытых для просмотра со стороны репозиториев, но принимать участие в работе над вашими бесплатными закрытыми проектами может не более пяти человек. При необходимости увеличении их числа вам придется покупать платный доступ к сервису.

В то время как многие из проектов можно вполне свободно выкладывать в общий доступ, разумеется есть и такие, которые надо хранить вдали от посторонных глаз, но работать над ними большими командами. Самым правильным выходом здесь будет покупка тарифного плана на одном из облачных сервисов или установка системы управления версиями на свой локальный сервер. Если же вам по каким-то причинам все же хочется получить полностью безлимитный доступ к BitBucket, аналогичный покупке тарифного плана за $80 в месяц (хотя бы затем, чтобы просто наслаждаться им, как вы радуетесь заполненному на 3,5% бесплатному пятидесятигигабайтному аккаунту на Дропбоксе), прошу под кат.

Многие из нас имеют аккаунт в сервисе Dropbox, о данном сервисе написано много статей и лайф-хаков, но сегодня я хочу вам показать, как можно заполучить заветный e-mail в зоне .edu за 15 минут.