Осторожно, трафик! Но можно хотя бы посмотреть картинки )

   Идея создать дома свой «рабочий кабинет» у меня зрела давно – как-то сам дошел до осознания его необходимости, хотя немалый вклад в начинания сделал этот давний пост на Хабре. У меня было своё рабочее место – большой удобный стол, где помещалось практически всё и даже больше… но, по сути, он был проходным двором – все время кто-то ходил, был рядом, отвлекал… такое очень часто мешает сосредоточиться и начать работать. Иногда, бывает, сидишь весь вечер за компом и понимаешь, что абсолютно ничего не сделал, хотя родным заявил «так, мне надо поработать».

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



Все произошло около полуночи 4 октября 2005 года в солнечном городе Лос-Анджелес. Тогда 19-летний хакер Сэми Камка выпустил в сеть нечто, более известное теперь как “червь Samy”. Это был первый самый быстрый и самораспространяющийся вирус, который навсегда изменил мир веб-безопасности.

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

Так как ранее я был разочарован количеством информации по этому вопросу, я решил восполнить этот пробел, собрав разные виды реализации 2Д платформеров, описав их сильные и слабые стороны и порассуждав над деталями реализации.

Моей целью было создать исчерпывающий и понятный путеводитель по реализации 2Д платформеров.



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

Четыре решения

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

Многие из нас работают над большими проектами. Тот, о котором расскажу я, живет вот уже 15 лет и имеет в своём составе пару десятков веб-приложений на ASP.NET WebForms, главное из которых содержит в себе около полутора тысяч aspx-страниц.

Зачем так много? Желание подстроиться под заказчиков с различными требованиями даёт о себе знать. Каждый хочет какую-нибудь свою особенную функциональность и в итоге получает её. Но речь не об этом. В довесок к большому числу страниц у нас было много стилей CSS. Очень много.


Источник: Ursus Wehrli. The Art Of Clean Up

В стандартном блокноте для всех версий Windows, начиная примерно с 2001 года, имеется ошибка, про которую практически все знают, но никто не собирается её исправлять. И это понятно, ведь это не критическая уязвимость, ничьей безопасности она не угрожает. Да и пользуется ли кто блокнотом вообще?

Тем не менее, сам факт довольно странный, поэтому мы попробуем найти эту ошибку в коде 64-битного и 32-битного notepad.exe от windows 7, исправим её, и выясним наконец, почему же она возникла. Заключается ошибка в следующем:

Если в блокноте включена опция «перенос по словам» (word wrap), то после сохранения файла начинаются всевозможные глюки: строки начинают разъезжаться, курсор улетает, текст вводится не туда, куда вы ожидаете, и так далее.

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

Сложилась ситуация, что участвую в проекте, который работает с достаточно большой нагрузкой. Как уже написал — 36 млн запросов в час. Я много чего прочитал и перепробовал за последний месяц, настраивая сервер; хотелось бы просто сжато и компактно выдать тезисно то, что работает хорошо в такой конфигурации.

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Это третья публикация по материалам нашей внутренней конференции Sync.NET. Первая публикация была посвящена многопоточности в .NET, вторая — реактивным расширениям.

При разработке front-end части приложения на языке JavaScript, мы можем столкнуться с рядом традиционных проблем. Все они решаются при помощи модульных подходов. Ниже мы рассмотрим самые популярные подходы для описания модулей в JavaScript, которые существуют на сегодняшний день.

Привет, Хабр!

Мы в HumanFactorLabs парсим адреса в особо крупных размерах. Наши продукты упрощают ввод контактных данных и работу с ними.

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

Недавно на Хабре нас попросили привести примеры необычных адресов, в связи с чем и написана эта статья.

Краткое содержание:

Возьмем немного функций высшего порядка, добавим частичное применение функций, приправим fold с map-ом и получим Javascript DSL для работы с DOM.

Человеческим языком:
Простое и понятное введение в функциональное программирование на чистом и понятном Javascript.

В отличие от «Через тернии к Haskell» все разжевано (возможно даже слишком) и разложено по полочкам.

Прочтение статьи развоплотит миф о неприменимости ФП в реальной жизни. Вы сможете смотреть на решение одной и той же задачи с разных точек зрения. Прямо как на картинке.

Иногда JavaScript может вводить разработчика в заблуждение, а иногда — доводить до белого каления из-за своей неполной консистентности. Есть в JavaScript некоторые вещи, которые только запутывают и сбивают с толку. Самые известные из них оператор with, неявные глобальные переменные и странное поведение при операции сравнения.

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

• DOM, который многие ошибочно считают эквивалентом самого языка JavaScript, обладает очень неудачным API.
• Когда переходишь на JavaScript с языков С и Java, то попадаешь в ловушку синтаксиса, который устроен не так, как в императивных языках. Это очень часто приводит к багам и сильно раздражает.

В результате JavaScript обрёл довольно плохую репутацию, которой он, в общем-то, не заслуживает. И чаще всего это связано с тем, что многие разработчики переносят на JavaScript свой опыт работы на Java или С/С++. Здесь разобраны три наиболее трудных случая, демонстрирующих разницу в подходах между Java и JavaScript.

Продолжая серию статей о новшествах в С#7, акцентирую внимание на, пожалуй, главных нововведениях — Pattern matching и Record type(Примерный перевод «регистрируемые типы»). Эти функционалы дополняют друг друга, поэтому лучше рассказывать о них вместе.

И словно говорят нам: «Я оракул,
Когда вещаю, пусть и пес не лает!»

Шекспир.

Так начиналась одна из глав руководства Oracle Database 6 для администраторов.

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



В этой статье мы рассмотрим процесс установки Oracle Database 12c на Windows Server 2008 R2 в облаке на один сервер. Развертывание кластерных конфигураций и тестирование производительности будет рассмотрено в следующих статьях.

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

Постановка задачи

Цель этого цикла статей — показать, как работает OpenGL, написав его (сильно упрощённый!) клон самостоятельно. На удивление часто сталкиваюсь с людьми, которые не могут преодолеть первоначальный барьер обучения OpenGL/DirectX. Таким образом, я подготовил краткий цикл из шести лекций, после которого мои студенты выдают неплохие рендеры.

Итак, задача ставится следующим образом: не используя никаких сторонних библиотек (особенно графических) получить примерно такие картинки:



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

Введение

В предыдущей статье мы изучили, как создать тему для WordPress. Давайте сегодня на основе этого же шаблона Corporate Blue попробуем создать сайт на второй по популярности CMS – Joomla! Поскольку в статье описывается в основном вёрстка, будем считать, что Joomla! у вас уже установлена. Если вы не знаете, как установить Joomla!, то инструкцию можно найти здесь. В данном руководстве мы не будем подробно описывать CSS стили и HTML код – это было сделано в самой первой статье. Вместо этого рассмотрим детально особенности создания шаблона именно для Joomla!

Привет, Хабр! Сегодня я хочу рассказать вам про наш относительно недавно созданный сервис капчи. Этот сервис отличается от аналогичных тем, что нашу капчу никогда чаще всего вообще не требуется разгадывать. Как известно, капча негативно влияет на конверсию — не все могут быстро ее разгадать, особенно если она неоправданно сложная, а часть пользователей уходят с ресурса. И я не знаю таких людей, которые любят ломать глаза и получают удовольствие от процесса разгадывания. Поэтому если избавить пользователя от необходимости вводить еще одно дополнительное поле, то это сделает его немножечко лояльнее.


^{Вряд ли кто-то сможет разгадать эту капчу :)}

Если в двух словах, то Некапча — это сервис интеллектуальной капчи, не требующий от человека прохождения проверки. Естественно, без дополнительной информации сервис не может ничего сказать о пользователе. Откуда же ее взять? Дело в том, что у Mail.Ru более 100 млн пользователей, причем большая часть из них авторизована. А это значит, что с запросом на наши домены передаются сессионные куки, по которым мы определяем пользователя, а затем достаем его профиль, статистику, спам-рейтинг и т.д. Вся эта информация подается на вход алгоритма-классификатора, и на выходе мы получаем предположение о том, кем является пользователь — человеком или спам-ботом.

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

31 января вышел релиз jQuery 1.5, одним из ключевых нововведений которого стал инструмент Deferred Object. Именно о нём я и хочу рассказать подробнее в этой статье.

Эта новая функциональность библиотеки направлена на упрощение работы с отложенными (deferred) вызовами обработчиков (callbacks). Deferred Object, аналогично объекту jQuery, «цепочный» (chainable), но имеет свой набор методов. Deferred Object способен регистрировать множество обработчиков в очередь, вызывать зарегистрированные в очереди обработчики и переключать состояние на «завершено» или «ошибка» для синхронных или асинхронных функций.

Так сложилось, что к тридцати годам я менял работу лишь единожды и не имел возможности на собственном опыте изучить, как в различных компаниях устроены веб-проекты, расчитанные на высокую скорость отклика и большое количество пользователей. <irony> Так что, дорогой хабраюзер, попавший в поле моего зрения в оффлайне, увидев меня, лучше беги, пока я не начал докучать тебе вопросами на тему обработки ошибок, логирования и процесса обновления на рабочих серверах&lt/irony&gt. Мне интересен не столько набор используемых технологий, сколько принципы, на которых построена кодовая база. Как код разбит на классы, как классы распределены по слоям, как бизнес-логика взаимодействует с инфраструктурой, каковы критерии по которым оценивается качество кода и как организован процесс разработки нового функционала. К сожалению, подобную информацию найти непросто, в лучшем случае всё ограничивается перечислением технологий и кратким описанием разработанных велосипедов, а хочется, конечно, более детализированной картинки. В этом топике я попытаюсь как можно более подробно описать, как устроен код в компании, где работаю я. Этот подход — мой суммарный опыт полученный за 10 лет разработки в разных компаниях.