Недавно у Эльбы вышло обновление, в котором появилась возможность сдать справки 2-НДФЛ за своих работников в налоговую. К нам тут же посыпалась куча испуганных возгласов от предпринимателей: «Что это еще за 2-НДФЛ? Когда сдавать? Почему я про это не знаю? Достали уже эти чиновники». И мы поняли, что немного испугали народ.

Ребята! Все окей — 2-НДФЛ сдается только за ваших сотрудников :)

Но подумав о наемных работниках, мы вспомнили, что не все фрилансеры стали акулами бизнеса и многим была очень интересна тема — как обычному трудяге можно законно изъять отданный государству подоходный налог. Мы решили отойти от своей ПроБизнес-тематики и просветить желающих: сегодня мы раскроем магию налоговых вычетов по НДФЛ.

Введение

Алгоритмы нечеткого поиска (также известного как поиск по сходству или fuzzy string search) являются основой систем проверки орфографии и полноценных поисковых систем вроде Google или Yandex. Например, такие алгоритмы используются для функций наподобие «Возможно вы имели в виду …» в тех же поисковых системах.

В этой обзорной статье я рассмотрю следующие понятия, методы и алгоритмы:

• Расстояние Левенштейна
• Расстояние Дамерау-Левенштейна
• Алгоритм Bitap с модификациями от Wu и Manber
• Алгоритм расширения выборки
• Метод N-грамм
• Хеширование по сигнатуре
• BK-деревья

А также проведу сравнительное тестирование качества и производительности алгоритмов.

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



DOM Storage (localStorage sessionStorage) кроме потрясающей возможности хранения информации на клиенте имеет ещё одну документированную, но малоизвестную возможность — уведомление об изменении/удалении элемента DOM Storage для всех окон открытых из текущего домена.

Совсем недавно мы выпустили в свет первую бета-версию нашей онлайн-читалки, с которой можно ознакомиться, почитав книгу Михаила Лермонтова «Герой нашего времени». Эта читалка — результат почти семимесячной работы, пять из которых ушло только на разработку движка. Казалось бы, в интернете уже есть бесплатные и открытые JavaScript-движки для чтения электронных книг и такой долгий срок может вызвать сомнения в профпригодности разработчика (то есть меня). Но есть одно большое и жирное «НО». Мы поставили перед собой слишком амбициозную и трудновыполнимую задачу: мы хотели использовать один и тот же движок на разных устройствах, в том числе маломощных, таких как айфон или электронная читалка.

В чём же заключается трудновыполнимость задачи? В первую очередь — в очень низкой скорости работы веб-приложений на айфоне. Например, мобильный Сафари по моим прикидкам работает раз в 100 медленнее своего десктопного собрата. Если на декстопе одна и та же операция выполняется 10 мс и совершенно незаметна для пользователя, то на айфоне она может выполняться больше секунды. Для сравнения: первая версия движка разбивала небольшую главу на страницы примерно за 15 секунд. Сейчас, спустя полгода, он делает то же самое менее, чем за секунду и вполне сносно работает в нашем приложении booq.

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

Стояла задача: найти или создать загрузчик файлов на сервер, использующий возможности HTML5 для мультизагрузки. Загрузчик должен:

• отправлять методом POST любые параметры вместе с файлом;
• отправлять куки;
• предоставлять возможность выбора сразу нескольких файлов (или нескольких тысяч – тут как пользователь захочет);
• отправлять файлы группами;
• файлы собираются в группы до определенного количества мегабайт, или до определенного количества файлов в группе; (это связано с тем, что на сервере есть ограничение на размер POST запроса и на количество файлов в одном пакете)

Именно по причине отсутствия опыта работы с флешем, для создания загрузчика был выбран только JavaScript.

Итак, что из этого получилось

В данной статье я хочу рассмотреть FileSystem API и File API, разобраться с его методами и показать пару полезных штук. Эта статья является компиляцией материалов с html5rocks (1, 2, 3). Все представленные ниже демки можно посмотреть по первым двум ссылкам. Третья ссылка так же предлагает ряд интересных демо. Ну а теперь займемся изучением материала.

Созданный нашими силами бесплатный pdf-журнал об играх вышел в очередной раз! На этот раз мы взяли интервью у создателя проекта «Пикселькит», который дает ностальгирующим геймерам возможность подключить правильный геймпад от SNES к PC (и даже к PlayStation 3).



Прочитать журнал на Issuu.com, либо скачать в pdf для PC или iPad с нашей страницы.

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

UPD: Спасибо отписавшимся за ценные советы.

В предыдущей части (http://habrahabr.ru/blogs/DIY/111610/) был рассмотрен первый шаг к созданию девайса, собственно выращивание кристалла. В этой части будем рассматривать физическое воплощение самого устройства и его электрическую схему.

Бывают ситуации, когда веб-приложению требуется поднять кучу данных с сервера, раскодировать их и отправить дальше по назначению. Примером этому может быть онлайн 3d редактор, где каждая модель может занимать несколько мегабайт в gzip'аном json'e.

Что же делать когда браузер среднего пользователя подвисает на секунду или даже больше при загрузке и распаковке данных?
1. Придумать что-нибудь на flash (я не уверен на 100%, но некоторые браузеры запускают плагины в основном потоке)
2. Загружать данные кусками, обрабатывать кусками.
3. Попросить пользователя сделать апгрэйд компьютера.

Все 3 варианта не очень, правда?

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

Автовставка точек с запятой (";") — одна из наиболее спорных особенностей яваскрипта, вокруг которой скопилось много непонимания.

Некоторые программисты ставят ";" в конце каждого оператора, некоторые — только там, где строго необходимо. Большинство же где-то посередине, хотя есть и такие, которые добавляют лишние ";" из стилистических соображений.

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

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

Что же такое проект?

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

Демо тут

Вступление

Предполагается, что читатель этого руководства, уже знаком с gen_server и gen_fsm поведениями, взаимодействиям посредством TCP сокетов с использованием модуля gen_tcp, активным и пассивным режимами сокетов, и принципом «OTP Supervisor».

OTP предоставляет удобный инструментарий для создания надежных приложений. Отчасти, это осуществляется путем абстрагирования общей функциональности в поведения, такие как gen_server и gen_fsm, которые связаны иерархией cупервизоров OTP.

Существует несколько известных шаблонов TCP сервера. Тот, который мы собираемся рассмотреть включает в себя один слушающий процесс и процесс создания нового FSM процесса на каждого подключившегося клиента. Хотя существует поддержка TCP соединений в OTP через gen_tcp модуль, не существует стандартного поведение для создания неблокирующего TCP сервера опираясь на принципы OTP. Под неблокирующим сервером мы подразумеваем, что слушающий процесс и FSM-процесс не должны делать каких-либо блокирующих вызовов и быстро реагировать на входящие сообщения (например, изменения в конфигурации, перезапуск и т.д.), не вызывая таймауты. Обратите внимание, что блокировка в контексте Erlang означает блокировку процесса Erlang, а не процесса операционой системы.

В этом руководстве мы покажем, как создать неблокирующий TCP сервер, используя gen_server и gen_fsm, которые предоставляют контроль над поведением приложения и полностью удовлетворяют принципам OTP.

Читателю, который не знаком с OTP, рекомендуется обратить внимание на руководство Джо Армстронга о том, как построить отказоустойчивые сервера с использованием блокирующих вызовов gen_tcp:connect/3 и gen_tcp:acceept/1 без использования OTP.

Часть 1
Часть 3

В части 1 мы создали (немного бесполезное) mochiweb приложение, которое отправяет клиентам сообщение каждые 10 секунд. Мы настроили ядро Linux, и создали инструмент, чтобы установить много соединений для проверки использования памяти. Мы выяснили, что требуется приблизительно 45 Кб для каждого подключения.

В части 2 мы превратим наше приложение во что-то полезное, и уменьшим потребление памяти:
• Реализация маршрутизатора сообщения с login/logout/send API;
• Обновление mochiweb приложения для работы с маршрутизатором;
• Установка распределенной erlang системы, таким образом, мы можем запустить маршрутизатор на различных узлах;
• Создание инструмента тестирования маршрутизатора большим количеством сообщений;
• График использование памяти в течении 24 часов, оптимизация mochiweb приложение для экономии памяти.

Это означает, что мы разделим логику доставки сообщений и mochiweb приложение. В тандеме с утилитой floodtest из части 1 мы можем протестировать работу приложения в условиях, близких к промышленным.
Реализация маршрутизатора сообщения

Продолжаю рассказывать о том, как я ставил на ноги Автотуристу.Ру.
Часть 1, Часть 2.

Глава 7. Цифры нефинансовые
Что ж, обещал в предыдущей части цифры и графики, буду держать своё слово. Сперва хотел бы продемонстрировать динамику роста моего проекта, начиная с первого посетителя и заканчивая 17.12.2010. Не знаю почему, но данные по уникам и просмотрам разительно отличаются в трёх основных (мною используемых) системах сбора статистики о посетителях: Liveinternet, Yandex.Metrica и Google Analytics. Лично я отдаю предпочтение последней по качеству и полноте отчётов, интерфейсу и авторитетности. Также, что, естественно в моих интересах, в GA фиксируется бОльшее кол-во посещений и просмотров страниц, нежели в двух остальных системах. Про Рамблер я промолчу, пожалуй.

Вот как по ГА выглядит обещанная динамика посещений:

Поскольку новость не пробежала на Хабре, но однозначно (с) будет интересна многим:

«Видео с пользовательской конференции по Sphinx (~8часов)
http://devconf.tv/user/sphinx».

Я оказываю услуги по настройке web- и БД-серверов. На днях ко мне обратился Иван Усачёв — владелец портала ochevidets.ru с просьбой избавить сайт от торможения.

Страницы в пиковое время стали долго загружаться, вплоть до 5 минут на страницу.

UPDATE: Статья была написана в 2010 году. Кое-что изменилось: вышли новые версии программ, у nginx изменились некоторые директивы и появились новые. Учитывайте это.

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

За этот год (а ведь и вправду прошло больше года) я поменял место работы и занимаюсь совершенно другими вещами и давно уже не программирую (много не программирую, если быть точным) на PHP. Новый проект обязал меня совершенствоваться в python'е (и ощутить его силу), поэтому однажды воскресным вечером было решено переписать и, главное, улучшить некоторые из своих библиотек для чтения текста. Сегодня я представлю на суд публики молодой opensource-проект Miette («вкусняшка», если переводить с французского), который призван (в каком-никаком будущем) читать файлы пакета Microsoft Office.

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

Естественно python во многом отличается от PHP и, на мой взгляд, имеет несколько больший функционал, поэтому и принцип построения библиотек в проекте несколько другой, нежели старая «поделка» на PHP. В данном случае было решено запретить себе, как разработчику и заказчику в одном лице, загружать какие-либо большие блоки в память. Мьетт читает данные постепенно, по требованию, как это делает сам Word. Это делает его легковесным и нетребовательным к оперативной памяти. В будущем, я постараюсь пройти исходные profiler'ем и найти узкие горлышка, которые стоит оптимизировать дальше.

Идём дальше?

В этой статье будут описаны различные настройки MySQL, преимущественно те, которые влияют на производительность. Для удобства все переменные разделены по разделам (базовые настройки, ограничения, настройки потоки, кэширование запросов, тайминги, буферы, InnoDB). Сначала уточним имена некоторых переменных, которые изменились в версии 4 MySQL, а в сети продолжают встречаться и старые и новые варианты имен, что вызывает вопросы.