Веб-разработка *

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

О чём речь?

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

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

В этом обзорном посте я бы хотел рассмотреть незаметные для пользователя методы защиты от ботов.

Методы защиты

Достаточно часто нам приходится хранить данные в memcached или MemcacheDB. Это могут быть относительно простые данные, например, закэшированные выборки из базы данных, а иногда необходимо хранить и обрабатывать более сложные структуры данных, которые обновляются одновременно из нескольких процессов, обеспечивать быстрое чтение данных и т.п. Реализация таких структур данных уже не укладывается в комбинацию команд memcached get/set. В данной статье будут описаны способы хранения некоторых структур данных в memcached с примерами кода и описанием основных идей.

Memcached и MemcacheDB в данной статье рассматриваются вместе, потому что имеют общий интерфейс доступа и логика работы большей части структур данных будет одинаковой, далее будем называть их просто «memcached». Зачем нам нужно хранить структуры данных в memcached? Чаще всего для распределенного доступа к данным из разных процессов, с разных серверов и т.п. А иногда для решения задачи хранения данных достаточно интерфейса, предоставляемого MemcacheDB, и необходимость в использовании СУБД отпадает.

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

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

Первым постом хочу затронуть одно из фундаментальных понятий при исправлении багов IE — hasLayout.

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

<ul class="tags">
    <li class="w1"><a href="#">amv</a></li>
    <li class="w2"><a href="#">anime</a></li>
    <li class="w3"><a href="#">music</a></li>
    <li class="w4"><a href="#">tnt</a></li>
    <li class="w5"><a href="#">авария</a></li>
</ul>


Классы w1, w2, w3 и т.д. расставляются по мере увеличения весомости тега и, следовательно, увеличивают размеры шрифта.

Для наглядности покажу, как это выглядит в браузере:

Идея совсем не нова. Идея древна.
Однако большинство наблюдаемых вокруг веб-фреймворков упорно игнорируют эту идею.

Она заключается в том, чтобы использовать континуации (continuations) для магического превращения RESTful (stateless) веб-приложений в более удобный и привычный stateful формат.

Всем привет.
Под катом — перевод статьи Джеффа Атвуда, в которой он приводит список 25 наиболее опасных ошибок в программировании от Common Weakness Enumeration со своими комментариями.

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

Этот пост — ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

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

Пример:
   выражение: «x + 10 == 5 * y / (1 + z*2)»;
   требуется уметь вычислять это выражение для любых значений x, y и z.

И конечно при этом надо учитывать приоритеты операторов.

Для решения нужно сделать компилятор, который по строке строит объект «Вычислимое Выражение». У этого объекта будет метод «вычислить для данных значений переменных».

Решение на Java, но может быть легко переведено на другие языки.

Иногда в проекте требуется проверить данные на предмет орфографических ошибок, не полагаясь на познания пользователя по части языков. Тут нам сможет помочь компания Google, с таким их сервисом, как проверка орфографии, используемым в Google Toolbar. Но, к сожалению, Google не предоставляет открытого API для работы с ним.

Итак, краткое описание:
Для того, чтобы проверить текст нам нужно отослать его в POST на https://google.com/tbproxy/spell?lang=ru, где для смены языка следует заменить значение параметра lang на соответствующий по ISO 3166-1 alpha-2. Текст оформляется в XML вида:

<?xml version="1.0" encoding="UTF-8" ?><br/>
<spellrequest textalreadyclipped="0" ignoredups="0" ignoredigits="1" ignoreallcaps="1"><br/>
 <text>Текст для проверки</text><br/>
</spellrequest>

ignoredups — подсветка повторов
ignoredigits — считать цифры ошибками
ignoreallcaps — не проверять слова написанные капсом (подсказал pointum)

Если всё успешно, мы получаем ответ вида

<?xml version="1.0" encoding="UTF-8"?><br><spellresult error="0" clipped="0" charschecked="272"><br> <c o="27" l="13" s="0"></c><br> <c o="73" l="11" s="1">орфографии и орфографии</c><br> <c o="190" l="11" s="1">пользоваться</c><br> <c o="226" l="13" s="0">пред оставляет пред-оставляет</c><br></spellresult>

Атрибуты тега spellresult:
error — произошла ли ошибка
charschecked — количество проверенных символов

В нем идет перечисление допущенных ошибок (теги c), их параметры:
o — начало исходного слова в тексте
l — длина этого слова
s — точность результата

В самом теге c содержатся предполагаемые варианты написания слов, разделенные символом \t.

P.S. Когда этот текст уже был написан, случайно наткнулся на статью в блоге Paul Welter, которая, в принципе, описывает тоже самое…


UPD: Пользователь wayly написал на PHP класс для проверки текста с помощью этого сервиса, скачать можно по ссылке proxysoft.ru/files/spellchecker.zip (зеркало).

UPD2: mezhevikin подсказал ajax-решение с использованием этого сервиса — orangoo.com/labs/?page_id=3

UPD3: Список поддерживаемых языков

_________
Текст подготовлен в ХабраРедакторе
Код подсвечен в Source Code Highlighter

Один из стандартных вопросов, который задает (или по идее должна задавать) веб-студия на первой встрече с клиентом – зачем вам нужен сайт? Зачастую клиент с готовностью отвечает «нам нужен сайт как инструмент». Но, как показывает опыт, иногда это примерно то же самое, что прийти в магазин и купить дрель, чтобы была. Чтобы в доме был инструмент.

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

С учетом того, что создание сайта – удовольствие чаще всего не дешевое, что же нужно сделать, чтобы инструмент не лежал на полке, а использовался по своему прямому назначению? Декларируя, что мы заказываем сайт-инструмент, надо понимать, какие именно «дырки» мы хотим получить в результате.

Давайте рассмотрим постановку задачи на примере.

Эта статья начиналась как комментарий к другой статье на habrahabr. После написания первого листа, я понял, комментарий слишком обширный получился :). Я решил написать, потому что хочу заострить внимание на моментах, которые, на мой взгляд, были упущены. Ограничение этой статьи — моя цель изложить всё максимально доступно, не ищите здесь математической точности в определении терминов, и всё же я прилагаю ссылки где математики найдут высококлассные понятные только им определения :)

Наверно каждую статью по JS принято начинать со слов о его недооцененности :) Это правда :) Когда я пару лет назад говорил о том что JS мой любимый язык на меня смотрели, как на школьника-переростка, который только что написал свою первую страницу на HTML, а те кто меня знал, как на гроссмейстера, который сказал что он только и знает как фигуры ходят :). Таких людей не стало намного меньше, увы :(

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

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

Сразу оговорюсь, это все мое личное мнение. Не навязываю, просто высказываю.

Сразу оговорюсь, что не являюсь профессиональным web-разработчиком, а занимаюсь этим just for fun, а также для саморазвития.
Потребовалось реализовать в моих разработках возможность комментирования. Простые структуры комментариев меня уже не интересуют, поэтому захотелось древовидности.
На первых порах старался реализовать ее самостоятельно, но потом решил обратиться к ресурсам интернета за чертежами изобретенных колес )))

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

Программисту удается написать код компилилируемый или интерепретиуемый, но не каждому понятный.

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

Недавно я писал про поиски способов получения иконок доменов в нормальном формате (т.е. png) и о желании написать свой отдельный сервис для этого, поскольку общедоступные конверторы от Google и Yandexа обладают существенными недостатками.

И вот он готов.

    Пол Грэм в своих эссе часто касается темы разработки снизу-вверх. Этот метод упоминается у него, когда он пишет о разработке програмного обеспечения, о способе ведения бизнеса, о преимуществах open source и блогах. Ниже я опишу почему при этой модели разработки взаимодействие с базой данных встает поперек глотки, и предложу решение уместное в некоторых случаях.

Задача очень специфичная, возникает только если вы разрабатываете web приложение для КПК.

Мне её предложил мой друг. Он реализовывал сбор информации о остатках на складе с помощью сканеров. Т.е. специальные аппараты под управлением Windows Mobile со считыванием штих кода, связанные по WiFi с сервером где храниться номенклатура товара. Реализовано было как web приложение, тонкий, да не очень клиент — Opera. Одна из задач — экономить время рабочих на работу с интерфейсом и минимизировать или совсем убрать повторяющиеся рутинные операции. Под задача — автоматический перевод фокуса на input'ы.

Выяснилось, что Opera метод focus для input работает не так как ожидалось — при вызове этого метода для input KEY_DOWN этим элементом не ловиться.

Возможно для кого-то это не новость, но я недавно столкнулся с данной проблемой: Антивирус Касперского заблокировал gif-анимацию.
После проведенных небольших экспериментов понял следующее:
Gif размером примерно до 50Кб он показывает только первый кадр, если размер больше, то не отображает вовсе.
Начал задумываться. Обычно при разработке сайтов проверяешь его в разных браузерах, может теперь стоит еще его проверять с разными антивирусами? :)