• Обзор CMS по категориям

      В мире существуют тысячи CMS для самых разных целей, самого разного качества, самой разной перспективы, стоимости, распространённости и так далее. Серьёзно опробовать их все — нереально. Поэтому когда я только знакомился с миром движков для сайтов, выбирать приходилось наугад. Ниже я опишу свои впечатления от знакомства с теми или иными движками для тех или иных целей. К некоторым приложу краткое описание особенностей, впечатление о прочих состоит только из заглядывания в админку. Заметки эти составлялись и редактировались в течении долгого времени, но сейчас я решил, что лучше опубликовать их в нынешнем виде, чем ещё полгода-год по чуть-чуть редактировать не добавляя ничего принципиально нового.
      Преимущество отдаётся бесплатным движкам. Платные будут рассматриваться только для сравнения или от безысходности, т.е. если нет бесплатных аналогов. Также ограничение на технологии: php. О движках на перле и питоне я не более чем слышал, на шарпе и джаве имел дело с самописными.
      Итак, рассматриваются
      Читать дальше →
    • Срезаем пики с RRD графиков на примере Munin

        Любой linux администратор наверняка наблюдал аномальные пики на RRD графиках. Пики появляются вследствие нарушения процесса сбора отслеживаемой величины и портят картину на графике. Это нормальное явление для RRD.

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

        image

        Читать дальше →
      • Проходим сквозь стены NAT-ов

          image Повсеместное распространение NAT казалось препятствует свободному обмену трафиком между компьютерами, находящимися за одним из них, и практически делает это невозможным, если оба компьютера скрыты за разными NAT серверами, естественно если вы не администратор обоих NAT серверов. Однако Samy Kamkar легко и непринужденно не только преодолел это, но и сделал программу которая позволяет преодолевать подобные препятствия. В настоящее время данная программа доступна только пользователям *nix подобных систем.

          Pwnat — этот инструмент позволяет любому количеству клиентов, находящихся за одним NAT-сервером, соединяться с сервером стоящим за другим NAT, при этом никакой проброски портов на серверах не требуется и никаких прочих инструментов не используется. Серверу не надо ничего знать о клиенте который с ним соединяется. Проще говоря это такой прокси сервер, который стоит за одним NAT и работает с клиентами, стоящими за другим NAT, между ними нет никакого дополнительного посредника, никаких DNS-фокусов и никакого пива админам. Скажу честно — я тоже в это сначала не поверил.

          Клиент может подключаться через такой сервер к любым ресурсам, либо только тем что ограничены сервером pwnat. Данный инструмент основан на построении UDP-тоннеля. Принцип работы весьма оригинальный и прекрасно описан автором, рекомендую ознакомиться, ибо решение данного вопроса оказалось весьма интересным и неожиданным. Давно не встречал ничего подобного.

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

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

            Сразу скажу, что получение денег на пластиковую карту без уплаты налогов может вылиться в серьезные проблемы (про ответственность написано в конце топика). Объяснения, что деньги «от бабушки внучку на мороженное» при суммах больше 10К$ в год уже не прокатывают, особенно если в реквизитах «бабушки» будет стоять что-то вроде «GMBH Star Development» Вероятность того, что возьмут за задницу достаточно высокая и поэтому лучше не рисковать и делать все по Закону, тем более, что ничего сложного в этом нет
            Читать дальше →
          • Обзор электронных платежных систем. Что выбрать?

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

              Итак, задача довольно тривиальная, и к её решению приступил с изучения предметной области.
              Читать дальше →
            • Пробуем TorrentStream — смотрим торренты онлайн

                Собственно, про топик-ссылку "On-line кинозал по протоколу p2p" про torrentstream.org. Скачал попробовать. Интересно.

                Что это? Просмотр фильмов в .torrent прямо в браузере, прямо по ходу скачивания.

                Коротко: в принципе работает; лучше чем uTorrent Stream; только Windows (Linux и Mac порты уже в разработке); удобства только только для FireFox; сам плеер работает и в IE и в Chrome тоже (ниже опишу как); качать надо довольно немаленький .exe (32mb); антивир — в комментах проверили KIS — норм все; плеер не понимает клавиатуры; есть подозрения про будущее проекта (слово «монетизация» слишком часто на сайте употребляется).



                Качать: сам плагин 32МБ (или прямая ссылка на скачивание), надстройка для FireFox для удобства.

                Внутри TorrentStream прямо рай для IT-шника кстати — сам написан похоже на Python 2.5 + wxWidgets + libvlc + Tribler (внутри немного покопаюсь в топике). Скомпилен py2exe. Есть еще какие-то куски от Lua — не понятно чего делающие. Собственно в распакованном виде: 26мб — только библиотеки Python+wxWidgets + 51МБ библиотеки libvlc (кодеки).
                Читать дальше →
              • Налоговая взялась и за фрилансеров в России

                  Недавно на хабре была заметка о том, как фрилансеров Беларуси проверяет налоговая. Эта история случилась совсем недавно уже в России.

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

                  Работаю я фрилансером уже около 4 лет, как ИП не зарегистрирован, все это время большую часть дохода вывожу WMR на карточку через банкинг от WM. Посчитал, за последние 3 года (вроде именно столько т.н. отчетный период) вывел на счет около 1 млн.руб. Налоговая вменяет незаконную предпринимательскую деятельность. Причем минимум, что мне грозит (как объяснили) — это уплата 13% со всего дохода плюс штрафы, максимум (что, как я понял, более вероятно) — уголовная ответственность и условный срок.

                  На следующей неделе буду консультироваться с юристами. Были ли подобные прецеденты в рунете?

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

                  UPD2 Насчет регистрации ИП: уточнял в налоговой плюс гуглил эту тему — работать по-белому можно только если есть договор с каждым заказчиком, который скорее выберет исполнителя без бумажных «заморочек».
                • Нынешние способы обмена Webmoney на ЯД и наоборот

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

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

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

                    Немного погуглив, можно найти много способов, все-таки обменять вебмани на яд и наоборот, некоторые из которых и публикую в этом посте. Считаю, что данная информация может пригодится :)
                    image

                    Читать дальше →
                  • Как FriendFeed использует MySQL для хранения данных без схемы

                    • Перевод

                    Условия


                    Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

                    По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

                    В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

                    Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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