Сегодня, 25 февраля, вышла версия 1.5.0 языка CoffeeScript. В ней впервые появилась базовая поддержка так называемого «грамотного» или «литературного» программирования (literate programming). Концепцию грамотного программирования придумал Дональд Кнут в 1981 году при разработке системы TeX. В отличие от исходного кода на обычном языке программирования, который включает в себя небольшие вкрапления комментариев, грамотное программирование подразумевает написание текстового документа на естественном языке с вкраплениями кода. Многие существующие системы грамотного программирования вообще не зависят от конкретного машинного языка.

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

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

Как и обещали, начинаем публиковать статьи по следам Design Camp. Начнем со статьи Евгения Гаврилова из команды интеграции дизайна Windows Phone.

1. Детали и их важность

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



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

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

Самыми оперативными откликнувшимися на мои запросы были создатели Path, им и слово. В следующих постах расскажем про приложения Twitter, 4square, Pedometer, Bump, Shazam и другие.

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

GitHub-юзер yawnt собрал чудесную подборку ссылок для любителей драконов, языков и прочих вкусных внутренностей. А знающие камрады в комментариях наверняка поделятся с тобой и другими яствами.

Пишет yawnt следующее:

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

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

В качестве введения

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

Каждый уважающий себя советский мальчишка должен был: знать, где найти карбид; быть влюблен в Алису Селезневу; хотеть стать космонавтом. Я в этом плане не исключение и, так сказать, полностью соответствовал. Со временем многое изменилось, но интерес к космосу остался. С января 2004 года я в течение полутора лет практически ежедневно заходил на специальную страничку НАСА и смотрел, что нового произошло с марсоходами. Так что документальный фильм «Смерть марсохода» (Death of a Mars Rover) был изначально обречен на ошеломительный успех среди меня.

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

"

В рассылке oss-security было опубликовано обсуждение различных уязвимостей, связанных с разбором XML. Уязвимостям подвержены приложения, которые разрешают библиотекам обрабатывать именованные и внешние сущности в DTD, встроенном в XML-документ, полученный из недоверенного источника. Т.е. по сути — приложения, не изменяющие настроек парсера по умолчанию.

Примеры XML-бомб под катом. Если у вас есть приложения, обрабатывающие XML, вы можете самостоятельно проверить их на предмет наличия уязвимостей. Проверка бомб в этом посте производится на примере утилиты xmllint, входящей в комплект поставки библиотеки libxml2, но можно использовать и другие синтаксические анализаторы.

Думаю многим известна особенность PostgreSQL, которая приводит к эффекту раздувания таблиц, или table bloat. Известно что она проявляет себя в случаях интенсивного обновления данных, как при частых UPDATE так и при INSERT/DELETE операциях. В результате такого раздувания снижается производительность. Рассмотрим почему это происходит и как с этим можно бороться.

Известно, что SQL — декларативный язык, который указывает, «что» мы хотим выбрать из базы, а «как» это сделать — СУБД решает сама. Задачу выбора для SQL-запроса конкретного способа его выполнения(плана) решает планировщик запросов, который есть практически в любой СУБД. Но иногда он выбирает не самый лучший план. Многие коммерческие СУБД предоставляют на этот случай «хинты», которые позволяют в ручном режиме подсказывать базе, как лучше выполнить запрос. В Open Source СУБД PostgreSQL такого механизма не было.

И вот, наконец, случилось то, о чем многие мечтали и чего уже устали ждать, а другие боялись. Японские разработчики из NTT реализовали хинты планера PostgreSQL. Причем, им удалось это сделать, не меняя ядро, в виде отдельного модуля pg_hint_plan, поддерживающего версии PostgreSQL 9.1 и 9.2. Модуль реализует хинты, позволяющие устанавливать методы сканирования и соединения таблиц, установку значений GUC. За деталями установки и использования добро пожаловать под кат.

Боже, временами я просто ненавижу объектно-ориентированное программирование.

Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят:

«Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”

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

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

Введение

В это статье я расскажу о применении инструмента изначально предназначенного для функционального тестирования при тестировании нагрузочном web части системы электронного документооборота (СЭД).

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

Буквально вчера опубликовали пост о фишинге в Gmail и в одном из комментариев @Chickey написал


Да я и сам с таким сталкивался:

Думаю, никто не будет спорить, что программный код должен быть чистым и «не пахнуть» (code smell), а паттерны проектирования и TDD должны стать верными спутниками любого мало-мальски грамотного разработчика на протяжении его нелегкой, но продуктивной карьеры. Все также знают, что цена ошибки в продакшине возрастает в десятки раз, а также то, что хорошие программисты оптимизируют код, а плохие — покупают новые сервера, а еще то, что 9 женщин не родят одного ребенка за месяц.



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

Как реализовать long polling с помощью Nginx и Javascript в сети достаточно много материала. Но полного руководства я ещё не встречал. То возникают проблемы с компиляцией модуля под Nginx, то в браузере вертится иконка загрузки при long poll запросах. Под катом, полный материал как же все таки это сделать правильно.

Задача: в массиве длиной N найти элемент, который повторяется больше N/2 раз.

Казалось бы, чего тут думать? Возьмём Dictionary<значение элемента, число появлений>, за один проход по массиву сосчитаем появления каждого элемента, потом выберем из словаря искомый элемент. Решение за O(N), куда может быть ещё быстрее?

Есть один нюанс: для словаря нам потребуется O(N) дополнительной памяти — в несколько раз больше размера исходного массива, и это при реализации словаря хоть хэш-таблицей, хоть деревом. Что будем делать, если наша цель — обработка сигнала неким устройством с маленькой памятью? Массив — замеры уровня сигнала, из которых один — «настоящий» передаваемый уровень, а остальные — шум и помехи. Неужели придётся для определения «настоящего» уровня возиться с хэш-таблицами и деревьями?

К счастью, нет: достаточно O(1) дополнительной памяти, и по-прежнему одного прохода по массиву.

«Инвестиции русских венчурных фондов не нужны тебе»
Так мог бы сказать джедай Йода

Есть у меня мобильное приложение в App Store, которое вначале было написано для эксперимента, а потом уже переросло в полноценный проект. Проект приносил прибыль, об инвестициях я и не помышлял, дорабатывал приложение, выпускал апдейты, прога подымалась в ТОПе App Store, деньги капали. Все текло неторопливо и размеренно. Первым «змеем искусителем» стал Аркадий Морейнис, который прислал мне письмо с предложением поучаствовать в программе акселератора Plug and Play Russia.

Продолжаем наше исследование игры «Сапёр» от Microsoft.

Данная статья является продолжением первой статьи.

О чем будет идти речь:
1) Взлом, основанный на переполнении буфера
2) Взлом игровых мин
3) Исследование архитектуры игры.

I

Откроем игру, следом за ней CE( Cheat Engine ). Присоединяемся к процессу игры: