Решил разобраться в вопросе блокировок в InnoDB. Получилась такая вот краткая шпаргалка. Может кому пригодится. Буду благодарен сообществу за найденные неточности

И так, в пределах одной транзакции, после…

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

После недавнего выпуска Retina MacBook Pro и The new IPad, экраны с увеличенной плотностью пикселей начали активно входить в нашу жизнь. Что это значит для веб-разработчиков?

Для начала разберемся в терминологии.

Физические пиксели

Кому интересно, как в несколько строк кода на С++ смоделировать вот такой параметрический бревенчатый домик — прошу под кат.

Давайте представим себе типичный, набирающий популярность стартап, использующий, например, PHP или Python. Сначала все находится на одном сервере — PHP (или Python), Apache, MySQL. Затем вы выносите MySQL на отдельный сервер, устанавливаете nginx для раздачи контента, возможно, добавляете memcached для кеширования и еще несколько серверов приложений…

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

Чтобы получить ответы на эти вопросы, в Badoo был разработан сервиc мониторинга и статистики в реальном времени — Pinba. В данной статье мы расскажем о нашем опыте использования его для мониторинга и профайлинга нашей системы.

RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.

Под катом перевод первого из шести уроков официального сайта. Примеры на python, но его знание вовсе не обязательно. Аналогичные примеру программы можно воспроизвести практически на любом популярном ЯП. [так выглядят комментарии переводчика, т.е. меня]

Update: из заголовка статьи убрано слово «неудачной». Подробности ниже!

Рассказывая в своей статье о типичных заблуждениях, связанных с защитой от SQL инъекций, среди прочих я отметил тот факт, что серверные подготовленные выражения не работают в PHP по заявленному эффективному сценарию — 1 раз prepare(), потом 1000 раз executе().

Ну, то есть, в теории-то они работают — в пределах одного запуска скрипта. Но много ли вы знаете скриптов (написанных профессиональными программистами), которые выполняют кучу одинаковых запросов? Вот я тоже не знаю. Повторяющихся запросов (каких-нибудь множественных апдейтов) — доли процента, а в массе своей запросы уникальные (в пределах одного скрипта).
Соответственно, для нашего уникального запроса сначала выполняется prepare(), потом — execute(), потом скрипт благополучно умирает, чтобы, запустившись для обработки следующего HTTP запроса, заново выполнять prepare()… Как-то не слишком похоже на оптимизацию. Скорее — наоборот.
Как верно заметили в комментариях, я должен был упомянуть исключения в виде консольных скриптов и демонов, которые долго держат соединение с БД. Однако основная масса PHP скриптов всё же работает на фронтенде, умирая после выполнения пары десятков запросов.

Но неужели нет способа как-то закэшировать подготовленный запрос между запусками?

… не пиратство. Даже близко не пиратство.

Мне сложно рассуждать, используя неточные термины, такие как «большая», «сильная» или как в данном случае: «невероятно высокая». Если вы утверждаете, что проблема Android — это большая доля пиратства на основе субъективного высказывания одного разработчика или на основе общего мнения, то это не аргумент.

Сейчас в интернетах можно встретить много Hello World'ов на WinApi, но когда новичок спрашивает как в этот Hello World добавить пару нужных функций — закидывают тухлыми яблоками и тут же отправляют в пресловутый и могучий MSDN.

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

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

«Моя дочь получила это по почте! – прокричал он. – Она еще в школу ходит, а вы посылаете ей купоны на детскую одежду и памперсы? Да как вы смеете! Вы хотите таким способом побудить школьниц рожать?»

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

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

Как Target узнал, что дочь беременна до того, как об этом стало известно ее отцу? Ответ прост – благодаря системе прогнозирования беременности (pregnancy prediction system), разработанной аналитиком компании Эндрю Полом. Под катом – обо всем по порядку.

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

В интернете существует множество учебников по использованию ATL, и в частности, по созданию COM-компонентов с его помощью, в том числе и ActiveX/OLE контролов, но большинство из них почему-то описывают процесс тыкания мышкой в разные интересные места Visual Studio, использование графических инструментов последней, и мало какой из них затрагивает нутро сгенерированного средой разработки кода в достаточно глубоком объеме. В русскоязычном сегменте интернета ситуация и того хуже — материалов по ATL крайне мало, практически нет(да и не только по ATL, а и по созданию COM-компонентов вообще), поэтому я решил этот недостаток компенсировать.

Intro

Привет, хабр! Ты наверное знаешь о недавних событиях, которые распиарили по интернету как «взлом» системы in-app покупок apple. Так вот, это было не совсем так. Это даже не было взломом. И ключевые выводы, которые я сделал:

• Закрытость<>Защищенность
• В Apple тоже очень даже ленивые люди работают

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

Технология

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

Начать свое присутствие на Хабре мы решили с материала, подготовленного для Конференции уральских веб-разработчиков, в котором описаны проверенные на собственной практике и оказавшиеся вполне успешными методы борьбы с DDoS-атаками. Целевая аудитория данной статьи — это программисты, имеющие в распоряжении vds или dedicated. Статья не претендует на полноценное руководство и многие сисадминские нюансы в ней намеренно опущены. Мы рассматриваем только DDoS типа http flood как наиболее распространенный тип DDoS и наиболее дешевый для заказчика.

Целевая аудитория данной статьи – это программисты, имеющие в распоряжении VDS или Dedicated.

Товарищи! Эта статья не для high-high-highload систем. Скорость работы представленных решений определённо меньше простейших проверок. На многотысячных или очень глубоких структурах применять предлагаемый подход крайне не рекомендуется. В этом топике побеждает быстрое кодирование, а не быстрый код.

Без длинных

Давайте без длинных вступлений, но всё же с предысторией. Однажды в рамках создания очередного очень важного компонента веб-сервиса нам понадобилось проверять уйму очень разных входных параметров (в данном случае, пришедших через $_REQUEST). Компонент был очень сложный, внутренняя и внешняя логика вызывала ежедневный баттхёрт между всеми участниками, а отдуваться приходилась немногим «избранным» программистам, которые писали, переписывали, выпиливали и запиливали заново. Когда на вход в систему с фронтенда падают десятки разных переменных, в том числе массивов, программисты при этом делают перекрёстные задачи (меняя логику) и мешают друг другу — код очень быстро разрастается, количество цепочек if-ов начинает занимать не одну страницу. Возвращаться к такому коду всё более и более чуждо ранимой душе. Тесты уже не очень помогают, т. к. каждое изменение логики приводит к изменению тех же тестов, в которых ещё надо вспомнить, понять и простить. Вот тогда и встал вопрос о создании удобного способа проверять весь входной поток каким-то приятным глазу способом, да чтоб всегда и везде получать фидбек про ошибки в однотипном виде. Акцент тут изначально стоял именно на удобстве для разработчиков, строго прошу в дальнейшем иметь.

На хабре в прошлом месяце была опубликована статья Конкурс ВК: Мессенджер для Android. Как это было!, в которой автор поделился своими мыслями о конкурсе и опубликовал список ресурсов и статей, которые помогли ему в создании приложения. Так как в последнее время я начал изучать разработку под iOS, то у меня скопилось некоторое количество ссылок, которые могут быть полезны для начинающих. Поэтому я последую его примеру и сделаю то же самое, только для своей платформы. Надеюсь, кому-нибудь они окажутся полезны и сэкономят немного времени.

(оригинал — Mike Ash, взято отсюда)

Многие Cocoa разработчики имеют довольно смутное представление об Objective-C Runtime API. Они знают, что он существует где-то там (некоторые не знают даже этого!), что он важен, и Objective-C без него неработоспособен, но обычно этим все знания и ограничиваются.

Сегодня я расскажу о том, как устроен Objective-C на уровне Runtime и о том, как конекретно вы можете это использовать.

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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

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

Как говорил ещё Артур Кларк, любая достаточно развитая технология неотличима от магии. Так и в веб-картографии — я думаю, все давно привыкли пользоваться географическими картами, но далеко не каждый представляет себе, как это всё работает.

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

Вот только незадача — вы совершенно не знаете, где находится ваш необитаемый остров, а без указания координат никто вас не найдёт, даже если выловит ваше письмо. Что делать? Как определить координаты без GPS?

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

Что было плохо?

• Было недостаточно проверок на соответствие чека и данных в SKTransaction.
• Было недостаточно проверок ответа сервера.