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

В чем же эта ошибка?

Добрый день, хотелось бы поделиться своим опытом. Я руководитель небольшого стартапа, в прошлом программист. Хотел бы рассказать о моем пути становления руководителем проекта(который продолжается конечно же), о проблемах с которыми пришлось столкнуться, ошибках, и позитивных моментах. Кому эта тема еще не набила оскомину — прошу под кат.

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

Задачи решаемые системой:
— удобная загрузка файлов;
— возможность асинхронной обработки картинок;
— легкая работа с превью;
— отделение конфигурирования от выполнения.

Поехали

В продолжение сегодняшнего топика Версионность и история данных — поделюсь простеньким инструментом, который мы используем.

Dklab_rowlog — это библиотека из нескольких хранимых процедур PostgreSQL, позволяющая добавить версионирование записей к любой таблице в БД. Иными словами, что бы ни происходило с таблицей, как бы данные там ни менялись (добавлялись/удалялись), это будет отражено в специальной табличке-логе.

Преимущества:

• Версионирование добавляется к любой таблице за 1 минуту с использованием 1 SQL-команды.
• Можно указать, какие колонки надо сохранять, а какие — нет (что экономит место). При этом запись в лог добавится только в случае, если хотя бы одна из указанных колонок изменилась.
• Можно указать колонку, которая будет трактоваться как «ID автора изменения».
• Можно задать колонки, которые будут логироваться в любом случае, независимо от того, менялись они или нет.

Примеры использования

Предположим, нам нужно логировать изменения вот в такой табличке:

С появлением новых проектов в сети иногда кажется, что задача эффективной организации пользовательских поддоменов (bob.someblog.com) кому-то представляется непростой. На самом деле, этот вопрос решается за одну минуту.
 

Этот топик — очередной топик про реализацию динамических поддоменов на сайте, коих много в интернете и даже есть пара топиков на хабре.

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

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

Например, у нас есть готовый сайт, на котором работают профили по такому url: www.example.com/users/username, и есть всякие дополнительные возможности (например www.example.com/users/username/contact и другие страницы, связанные с этим юзером).

И мы теперь хотим вынести все, что связано с юзером, на поддомен, например username.example.com, username.example.com/contact и т.д.)

Решения, которые были найдены в интернете, меня не удовлетворили по 2 причинам:

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

На нашем сайте стоит nginx над апачем (как и на многих других), поэтому пришлось изобретать велосипед самому, используя эту связку (nginx+ apache, благо сейчас почти на всех крупных сайтах стоит проксирующий nginx над апачем)

При разработке баз данных зачастую требуется обеспечить поддержку версионности и хранения истории объектов. Например, у работника может изменяться должность, у должности в свою очередь может меняться оклад — в многомерном моделировании это называется Slowly changing dimensions(далее SCD) — редко изменяющиеся измерения, то есть измерения, не ключевые атрибуты которых имеют тенденцию со временем изменяться. Всего существует 6 основных типов(методов) SCD, которые определяют как история изменений может быть отражена в модели.

Как ни странно звучит, но речь действительно пойдёт про usability кабинки туалета.

Цель статьи — немного размять мозги.

Сейчас многие говорят про usability. Но не многие всерьёз о нём задумываются.

— Сделаю-ка я высовывающуюсь панельку на своём сайте. Ведь это же… как его… юзабельно!

Но сейчас я хочу поговорить не про веб-интерфейсы и вообще не про интерфейсы, а про устройство кабинки туалета.

Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на JavaScript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, тобишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взгялнул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

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

Summary

Announced: 2010-05-20
Credits: 80sec
Affects: сайты на ngnix+php с возможностью загрузки файлов в директории с fastcgi_pass

Background

Зачастую How-To по настройке связки nginx с php-fpm / php-cgi есть подобные строчки:

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}

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

Вы пытались когда нибудь взломать зашифрованный rar архив? И сколько паролей в секунду оно перебирало? 50-100-200? Даже на хорошем GPU, при использовании небезызвестного cRARk, скорость перебора всего около 2400 вариантов/сек. И это-то по сравнению с десятками (сотнями) миллионов паролей/сек для zip/md5/SHA1.

Под катом моя вольная интерпретация этого процесса.

Q:

В Facebook используют MySQL зная, что он плохо масштабируется (или здесь какая-то особая магия?). Я хотел спросить, из каких соображений они выбрали MySQL? Используют ли JOIN'ы? И не планируют ли перейти на другую БД?

A:

Отвечает Adam D'Angelo, бывший CTO Facebook, сейчас он развивает свой стартап Quora:

1. Если разбивать данные по разным серверам на уровне приложения, то масштабируемость MySQL не такая уж и большая проблема. На 2008 год, в Facebook [1] у нас было 1800 MySQL серверов для которых требовалось всего два администратора. Конечно, вы не сможете сделать JOIN с данными с разных серверов, но NoSQL-базы вам тоже этого не позволят. Нет никаких данных о том, что в Facebook используют Cassandr'у как основное хранилище, и, кажется, что единственное, для чего она там нужна — это поиск по входящим сообщениям. [2]

Как показывает практика, качественный распил изготовление сайта госучреждения не всегда является технически качественным.
18 числа сего месяца ребята с hack-world.org, не особо напрягаясь, добрались до админки http://www.kazcosmos.kz/, ныне благополучно почившего, похоже, на ремонт и заделку дыр в движке.

Видео процесса:

UPD: Обсуждение взлома: http://hack-world.org/showthread.php?t=5133
Собственно, сама SQL-инъекция: http://hack-world.org/showthread.php?t=5131

Государство всячески старается поддержать малый бизнес и предпринимательство. Создаются бизнес-инкубаторы, учреждается грантовая поддержка и т.п. Но как всегда все получается через попу. Вот моя небольшая история о том как, как начинающий предприниматель (ИТ) пытался получить грант…



Стоит немного уточнить что такое грантовая поддержка от государства… Грант — это по сути возмещение фактических затрат, которые понес предприниматель при создании своего дела. Причем затрат исключительно на оборудование, аренду, сырье и т.п. Также предприятие должно существовать не более года. Для получению гранта надо собрать разного рода справки и документы (выписки из ЕГРИП/ЕГРЮЛ, справка о наличие р/с и т.д.). А также предоставить «бизнес-план» (почем у в кавычках читайте ниже).

(Окончание этих двух топиков — переводов эссе «Unmaintainable Code». В оставшихся главах автор часто обращается к уже описанным методам, удваивая и утраивая каждый из них; изложение сильно сокращено за счет исключения таких мест.)

Тестирование

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

И не всегда то, что фотография может «сказать», будет приятно ее владельцу. В общем, речь пойдет о давно наболевшей проблеме — неосторожности пользователей Интернета и утечке личной информации. Дело в том, что большое количество новых моделей сотовых оснащены функцией геотаггинга, и как-то очень немного людей, которые понимают потенциальную опасность этой функции. На вчерашней конференции хакеров Next HOPE один из участников рассказал, что он проанализировал более 2,5 миллионов фото, вывешенных пользователями сервиса Twitter, и более 65 тысяч из них оказались помечены координатами.

Команда Jupiter IT выпустила Syn, библиотеку, которая позволяет вам создавать синтетические события для использования при тестировании. Эта отдельная библиотека предназначена для оказания помощи в тестировании сложного поведения пользовательского интерфейса, имитируя действия пользователя, такие как печать с помощью клавиатуры, нажатие кнопок мыши и перетаскивание с её помощью.

Каждый, кому приходилось писать объемные куски осмысленного кода на javascript, рано или поздно понимал, что ему многого не хватает в этом языке или просто неудобны некоторые врожденные конструкции. Для сглаживания шероховатостей применяются jQuery, Prototype, MooTools etc. Кто-то уже мало представляет себе, как можно кодить без них. Сегодня я расскажу о еще одной маааленькой библиотечке, которая делает мир javascript-программиста еще прекраснее. Речь пойдет о Underscore.js

Продолжение этого топика — вторая и третья главы эссе «Unmaintainable Code». Несколько перекликается с первой, но описанные методы уже не так очевидны (а некоторые отличаются поистине дьявольской изобретательностью и не меньшей злокозненностью). Ах да, с заявленного в прологе языка Java автор незаметно переключился на C/C++.

Камуфляж

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

Программисты с Etsy.com поделились опытом, как им удалось эффективно решить задачу по пакетному ресайзингу фотографий с 1,5 МБ до 3 КБ (после смены дизайна оказалось, что старые превью-окошки не вписываются в новые шаблоны страниц). Задача не такая банальная, как кажется. Дело в том, что Etsy.com — крупный интернет-аукцион, и количество изображений различных товаров превышает 135 млн штук.

Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда. Затем они начали считать, можно ли отдать пакет в облако EC2 и во сколько это встанет. Посмотрев на получившуюся сумму, программисты решили поискать другой способ.

В итоге им удалось завершить обработку 135 млн фотографий всего за 9 дней, задействуя четыре 16-ядерных сервера. Средняя скорость обработки составила 180 изображений в секунду.