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

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

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

Добро пожаловать в мир типографики и относительных единиц измерения =)

Многие считают, что гибридные приложения не могут иметь хорошую производительность, особенно в плане построения страницы (то есть имеют низкий FPS). Это ошибочное мнение. Если умело собрать приложение, то можно добиться хороших показателей. В статье рассмотрен пример сборки такого гибридного приложения под Android в Windows 7 (хотя для iOs будет почти тоже самое).

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

Многие студенты, впервые сталкиваясь с описанием какой-нибудь хитроумной штуки, вроде алгоритма Кнута – Морриса – Пратта или красно-чёрных деревьев, тут же задаются вопросами: «К чему такие сложности? И это, кроме авторов учебников, кому-нибудь нужно?». Лучший способ доказать пользу алгоритмов – это примеры из жизни. Причём, в идеале – конкретные примеры применения широко известных алгоритмов в современных, повсеместно используемых, программных продуктах.



Посмотрим, что можно обнаружить в коде ядра Linux, браузера Chromium и ещё в некоторых проектах.

Внимание! В рецепте с отбеливателем обнаружилась опасность коррозии металла! Не рекомендуется в стандартном применении!

Обзор экспериментов год спустя:
DIY порошок для посудомойки: как не растворить посуду и не повторить моих ошибок. Год экспериментов

В прошлой публикации мы создавали дешевый порошок для посудомойки из желудей и спичек кальцинированной соды и стирального порошка. В этой я расскажу о том, как можно его улучшить с помощью кислородного отбеливателя и где можно купить компоненты для более продвинутой версии. Будем делать упор на эффективности мойки, но даже при этом цена не выйдет за 100 рублей/килограмм. А еще будет рецепт ополаскивателя с себестоимостью в районе 1 рубля за литр. Как справедливо заметил amarao, занятие не для всех и многим проще использовать готовые таблетки. Но в подобных экспериментах с бытовой химией есть что-то от детства, первых опытов по смешиванию соды с уксусом и газировки с мятными конфетами. Так что ощутимая экономия здесь все-таки вторична. Будем развлекаться) Если кому-то лень читать весь текст — в конце поста будут подробные рецепты с рекомендациями.

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

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

Этой статьёй хочется облегчить порог вхождения в чистый WebGL, дать начальное представление и подсказать, куда двигаться дальше.

Урок по реализации круглой кнопки загрузки (далее progress button) by Colin Garven. Будем использовать, описанную by Jake Archibald, технику анимации SVG линий для того, чтобы анимировать progress button и показать пользователю состояния «success and fail».

Всем привет. Это снова «Без слайдов», и сегодня у меня для вас интервью с Дмитрием Нестеруком aka mezastel, техническим евангелистом компании JetBrains. Дмитрия я знаю довольно давно и, не скрою, сам очень долго ждал момента, когда мы наконец поедем на студию и запишемся. Уж больно много вопросов у меня к нему накопилось.



Мы больше часа беседовали с Дмитрием, но не успели затронуть даже половины тем, которые хотелось обсудить. Что Дмитрий успел рассказать мне:

• Чем технический евангелист отличается от Developer Advocate
• Как работает евангелизм в JetBrains
• О восприятии мира настоящими гиками
• Почему IT — это бедная индустрия
• Про маржу и инвестиции российских аутсорсеров
• Про то, какие enterprise решения позорят индустрию и почему
• Насколько далека JetBrains от своего простого потребителя
• Об том, как индустрия видеоигр смогла «вырастить» под себя целый сектор железа
• Что сейчас творится на рынке видеокарт
• Что еще могут придумать компании, для того, чтобы программы работали быстрее
• О том, как будет выживать ReSharper и о 64-битных IDE от Microsoft

Вот видео, а под катом, как обычно, текстовая версия этого интервью.


(на одиннадцатой минуте нет звука, к сожалению.)

Привет, Хабр! В этой статье речь пойдет о том, как мы в компании Mail.Ru Group подходим к написанию кода; когда использовать готовые решения, а когда лучше писать самим; ну, а самое главное — какие шаги нужно сделать, чтобы ваша работа не оказалась безрезультатной и принесла пользу окружающим. Все эти нюансы будут рассмотрены на примере задачи создания нашей внутренней JSSDK, которая возникла из-за необходимости объединения кодовой базы двух проектов.


Иллюстрация Michael Parkes

Если вы программист (или чего хуже архитектор), то можете ли вы ответить на такой простой вопрос: как писать НЕ тестируемый код? Призадумались? Если с трудом можете назвать хотя бы 3 способа добиться не тестируемого кода, то статья для вас.

Многие скажут: а зачем мне знать, как писать не тестируемый код, плохому хочешь меня научить? Отвечаю: если знать типичные паттерны не тестируемого кода, то, если они есть, можно легко увидеть их в своем проекте. А, как известно, признание проблемы — уже половина пути к лечению. Также в статье дается ответ, как собственно осуществляется такое лечение. Прошу под кат.

Впервые я столкнулся с Upwork (тогда еще oDesk) в 2011м году, когда брат прислал на них ссылку в скайпе. Я только начинал работать на русских биржах, и подумал — почему бы не попробовать еще и на зарубежной. Но тогда все закончилось ничем. Результаты были слабыми, и, разочаровавшись во фрилансе как таковом, я бросил это дело.

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

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

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

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

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

На самом деле этот пост был подготовлен еще в апреле 2014 года, я не смог тогда его опубликовать. Являлся вторым в ожидавшейся серии. Можете глянуть первый. На эту тему писать меня сподвигло желание внести немного ясности в представления о некоторых химических аспектах нашего бытия. Пользуясь тем, что химия — наука, не слишком популярная в массах, нам иногда рекламщики и пресса выдают такие перлы, что у меня не хватает слов для описания эмоций. Так что попробуем слегка рассеять туман, ну и чтоб это было интересно и актуально для наших условий. Недавно встретил похожую переводную публикацию, тоже про соль. Серьёзную и хорошо сделанную, правда, слегка не о нашей действительности.

Итак — про соль


Так в Африке ею и торгуют. Толщина кусков, вероятно определяется толщиной пласта. Слабенькие пласты.

Солить или не солить. А зачем вообще соль, может лучше без неё? Заменитель соли? Ценная соль с минералами и розового цвета — а зачем козе баян? Рекламные посты — хороший способ приготовить лапшу на уши.

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



Краткая предыстория. Стала перед нами задача: изготовить энное количество резиновых кнопок от ключей автомобиля по образцу. Пробовали мы их печатать на 3D принтере из резинового филамента, но качество не устроило. Тогда-то и пришла мысль реверсировать технологию литья в силикон. Что из этого вышло, читайте под катом.

За прошедшие почти 10 месяцев с релиза 1.0.0 была очень большая работа по улучшению программы.

Из основных изменений стоит отметить следующие:

• Возможность выявлять самые популярные виды атак: syn_flood, icmp_flood, udp_flood, ip_fragmentation_flood
• Добавление поддержки протокола Netflow, поддерживаются 5, 9 и 10 (IPFIX) версии
• Добавление поддержки протокола sFLOW v5, который поддерживается большинством современных сетевых коммутаторов
• Добавлена поддержка использования netmap (поддерживаются Linux и FreeBSD, для Linux предоставляется специальная версия драйвера ixgbe: github.com/pavel-odintsov/ixgbe-linux-netmap) для захвата пакетов. Данный режим обеспечивает наивысшую производительность захвата трафика наряду с PF_RING ZC.
• Добавлена поддержка PF_RING ZC (к сожалению, этот режим требует отдельной лицензии на библиотеку PF_RING)

• Игровой backend: из каких модулей он должен состоять?
• Расчет параметров персонажа: виртуальные методы или сложение массивов?
• Логика поведения: на каком уровне она должна находится?
• Перемещение персонажей: кто этим должен управлять?

        Сегодня мы продолжим знакомиться с разработкой и проектированием он-лайн игры на примере космической ММО RPG «Звездные Призраки». В этой статье речь пойдет о backend'е на С++ и она будет насквозь техническая.

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

        В статье мы сосредоточимся именно на архитектурных решениях применительно к backend'у MMO RPG в реальном времени. Исходного кода будет не много и он точно не будет содержать таких специфических для С++ вещей как множественное наследование или шаблоны. Задача данной статьи помочь в проектировании игрового сервера и ознакомить всех желающих со спецификой игрового backend'а.

        Описываемые решения достаточно универсальны и вполне подойдут для многих RPG. В качестве иллюстрации в конце статьи я приведу пример использования описанной архитектуры в игре «про эльфов».

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

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

Обзор

RefluxJS — простая библиотека, обеспечивающая в вашем приложении однонаправленный поток данных, использующая концепцию Flux от Facebook.

Всем привет! Мы, в компании Cackle, занимаемся разработкой облачных SaaS-решений для сайтов с 2011 года. Наши продукты установлены более чем на 10 000 сайтах, каждый день мы обрабатываем в среднем 65 миллионов уникальных хитов. Полоса пропускания (bandwidth) в пики доходит до 780 мбит/сек, а БД в сутки принимает до 120 миллионов запросов на чтение, и до 300 тысяч запросов на запись. Такие нагрузки заставляют изобретать непростые решения, частью которых мы и хотим поделиться.