В программировании самокритика – это умение распознать контрпродуктивные решения в дизайне, коде, процессах и поведении. Знание о вредных шаблонах решений полезно для программиста. В этой статье я опишу анти-паттерны, которые я встречал на своём личном опыте время от времени.

Некоторые из них напрямую или косвенно связаны с когнитивными искажениями человеческого сознания – в этих случаях я даю ссылки на соответствующие вики-статьи. Также интересен список известных когнитивных искажений.

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

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

Как избежать

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

Одним пасмурным утром я подумал, что было бы неплохо хорошенько прорефакторить один из моих старых проектов. Это некоммерческое легковесное приложение для кастомизации HUD в одном 3Д шутере. Писал я его 2 года назад, был горяч и неопытен. В результате куча отменного спагетти-кода, который, несмотря на все свои недостатки, делал своё дело. Став мудрее и опытнее, я решил полностью переписать приложение, дать ему новую архитектуру, упростить поддержку и обновление. Как это сделать? Ответ казался простым — использовать MVC, разделить на уровни и связать всё в единое целое. Так я столкнулся с проблемой выбора простого и эффективного фреймворка, который станет прочным фундаментом. После быстрого исследования я выбрал backbone.js. Очень понравился своей простотой и гибкостью. Можно просто открыть исходники и понять, как всё устроено и работает. Единственный нюанс, который не радовал — MV-паттерн. Размазывать логику по многочисленным views очень не хотелось, так родилась идея написать свой велосипед, который предоставит недостающие части головоломки. Плюс, создание чего-то нового — это всегда увлекательно и интересно. Недолго думая, я приступил к реализации контроллеров для backbone.

Технологии хранения данных — отдельная тема. Не так давно мы косвенно затрагивали ее в нашем материале об управления дисковым пространством сервера.

Сегодня мы поговорим о том, как команда поискового сервиса Algolia пыталась решить внезапно возникшую проблему с SSD-дисками.

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

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

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

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

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

Одной из особенностей JavaScript, которая делает его столь удобным для функционального программирования, является то, что он может принимать функции высшего порядка. Функция высшего порядка — это функция, которая может принимать другую функцию в качестве аргумента или возвращать другую функцию в качестве результата.

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

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

Введение

Я люблю функциональные языки за их простоту, ясность и предсказуемость. Пишу в основном на Elixir / Erlang / OTP, пробовал другие языки, но Erlang с его акторами пока мне гораздо ближе чем например Lisp или Haskell. Как известно Erlang == web, а у чего-либо написанного для веба порой бывает клиентский веб-интерфейс: html, css, js — содержимое. Увы js это стандарт современного веба, для него есть библиотеки почти под любую задачу почти на все случаи жизни, да и это более-менее единственное доступное средство что-то выполнить в браузере на стороне клиента. Поэтому нам всё-таки нужен js. Сперва мне подумалось «Лямбды и функции высшего порядка есть, значит писать на js будет просто. Выучу синтаксис и буду писать так же как пишу в Erlang/Lisp/Haskell». Как же я ошибался.

После моего недавнего выступления на MoscowJS #17 с одноимённым докладом у многих возник интерес к этому инструменту. В рамках 11-го выпуска RadioJS, Миша Башкиров bashmish рассказал, что решился попробовать его в своём новом проекте, об успешном опыте и множестве положительных эмоций. Но были озвучены вопросы и возникла дискуссия, в результате которой я решил написать эту статью, чтобы раскрыть основные тезисы с доклада и рассказать о том, что тогда не успел.
Статья ориентирована, как на профессионалов, так и на тех, кто с похожими технологиями ещё не сталкивался.
Итак, начнём.

Интро

Не так давно я выступал на конференции FrontendConf 2015 (РИТ++) с темой данной статьи. И при подготовке доклада начал искать информацию, а кто вообще выступал на данную тему и что есть в Сети на данный момент.

Оказалось, что информации совсем немного, более-менее можно было бы отметить доклад mikewest.org/2013/09/frontend-security-frontendconf-2013 от Mike West из компании Google, но какой-то «непентестерский» взгляд и уж совсем мало материала. И www.slideshare.net/eoftedal/web-application-security-in-front-end где тема раскрыта более детально, но выступление 2011 года. А за 4 года технологии и атаки на месте не стояли.

Долго и сложно выбирая темы, что же все-таки рассказать разработчикам фронтендов про безопасность, при этом минимум касаясь бекэнда (местами все-таки это неделимо), получился доклад, а здесь — его текстовый пересказ.

О чем вообще разговор?

А действительно, о чем тут вообще можно разговаривать? Говоря про взломы и безопасность невольно приходят в голову тезисы — слили базу, получили доступ к выполнению команд ОС на сервере, прочитали чужую переписку. Но это все — server side код. А что ж может «нагородить» фронтэндер? Главная опасность, конечно же, в обходе атакующим SOP — Same Origin Policy, главной политики безопасности браузеров, которая регулирует работу в разных Origin. Но не только, давайте разбираться.

Оригинал: React To The Future With Isomorphic Apps

Изоморфные приложения. Взгляд в будущее с React

В разработке программного обеспечения все часто возвращается на круги своя. Так, например, на заре развития Интернета серверы подгружали контент сразу же на сторону клиента. В последнее же время, с разработкой современных веб-фреймворков, таких как AngularJS и Ember, мы видим тенденцию к обработке запросов на стороне клиента и использованию сервера только для API. Однако, это далеко не единственная тенденция. Сейчас происходит медленное возвращение или, скорее, слияние этих двух архитектур.

Пытаясь разобраться с библиотекой от Facebook ReactJS и продвигаемой той же компанией архитектурой «Flux», наткнулся на просторах интернета на две занимательные статьи: «ReactJS For Stupid People» и «Flux For Stupid People». Чуть раньше я поделился с хабравчанами переводом первой статьи, настала очередь второй. Итак, поехали.

Flux для глупых людей

TL;DR Мне, как глупому человеку, как раз не хватало этой статьи, когда я пытался разобраться с Flux. Это было не просто: хорошей документации нет и многие ее части перемещаются.

Это продолжение статьи «ReactJS For Stupid People».

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

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

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

Как правильно подойти к этому процессу? Мне нравится подход в гибких методологиях разработки. Чем же они так нравятся разработчикам? Думаю, что тем, что их можно подстраивать под себя. Главная идея, из которой я предлагаю исходить — это набор правил, при этом каждый может выбирать из них те, что подходят именно ему, может дополнять, исходя из своих потребностей.

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

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

Во всех современных системах сборки фронтенда есть режим watch, при котором запускается специальный демон для автоматической пересборки файлов сразу после их сохранения. Также он есть и gulp.js, но с некоторыми особенностями, делающими работу с ним немного сложней. Работа gulp.js основана на обработке файлов как потоков данных (streams). И ошибки в потоках не всегда можно перехватить, а когда ошибка случается, то будет выброшено неперехваченное исключение и процесс завершится.

Чтобы этого не происходило, и watcher мог игнорировать отдельные ошибки и запускаться снова и снова при сохранении файлов, в gulp нужно сделать несколько дополнительных настроек, о которых и расскажется в этой статье.

В этой статье я попробую рассказать о способе хранения уровней в ROM-памяти картриджей для приставки NES.
Я опишу все основные способы и подробно остановлюсь на наиболее часто используемом (из нескольких десятков исследованных мной игр он встречался практически в каждой).

Данный способ я назвал «блочным» (оговорюсь, что многие термины в статье были придуманы мной, так как материалов на данную тему на русском нет; после исследования нескольких игр я занялся изучением англоязычных материалов и документации к редакторам игр для старых платформ, тогда уже нашлись некоторые аналогии, в таких случаях буду приводить свои термины с объяснением их значения и их английские версии). В качестве примеров я буду приводить уровни из игры «Darkwing Duck», а также других игр компании «Capcom», разобранных мной несколько лет назад.

Я постараюсь пропустить описание использования дизассемблера и техническую часть исследования (если будет интерес, можно сделать на эту тему отдельную статью), а остановлюсь на описании, как именно разработчики хранили данные. Зная, что именно искать, найти это внутри образа ROM станет намного проще. Бонусом я покажу готовый редактор уровней и несколько созданных на нём хаков классических NES-игр.

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

Работа, изобретения, озарения, предательство и создание электроавтомобиля

Реакция Илона Маска (в центре) на первое публичное размещение, AP Photo/Mark Lennihan

Существование Tesla противоестественно. Последний успешный автомобильный стартап Америки, который поразил весь мир своими новыми технологиями, основали 111 лет назад, и назывался он «Форд».

Компания, возраст которой едва превысил 10 лет, стоит более 30 миллиардов долларов. Да что фондовый рынок, её тихо обожают абсолютно все, от любителей зелёной энергетики и фанатов искусственного интеллекта до простых автомобилистов. Банковский холдинг «Морган Стэнли» назвал Tesla важнейшей автомобильной компанией, а Tesla Model S стала самой любимой машиной США в 2014 году.

Всем привет! Я Егор Дыдыкин, руководитель группы разработки главной страницы Mail.Ru. В этой статье я расскажу о том, как мы решали задачу по созданию адаптивного портального меню — блока, расположенного в верхней части практически каждой страницы проектов Mail.Ru. Создавать, развивать и модифицировать любые кросспортальные решения (к которым относится и наше адаптивное меню) – это всегда объемная и сложная задача. Трудность работы с такими элементами в том, что они используются на всех проектах портала Mail.Ru — и соответственно, должны учитывать технологическую и продуктовую специфику каждого из них. Необходимо, чтобы портальное меню было технически независимо и могло работать в любой среде — легко встраиваться в каждый из проектов и соответствовать их логике.

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



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

А теперь подробнее о том, как мы это сделали.

Здравствуйте, коллеги.

Сегодня мы хотели затронуть такую многогранную и противоречивую тему, как фреймворки JavaScript. За последние несколько месяцев в издательстве неоднократно обсуждались перспективы издания книг и по Angular.js, и по Knockout.js, а книга по Backbone.js у нас выходила в прошлом году. Следующий материал призван помочь разобраться в сильных и слабых сторонах различных фреймворков JavaScript. Возможно, после изучения статьи читателю будет проще ответить на вопросы о том, так ли схожи эти фреймворки, и желает ли он дополнительно изучить какую-то из технологий, упомянутых в этом обзоре. Мы же попросим вас поделиться вашими соображениями о том, нужны ли новые книги по этим фреймворкам, если да — то по каким (высказываемся в комментариях, не стесняемся давать ссылки на книги).

Как следует из официальной документации, React.js — V из MVC, и, как правило, вместе с ним применяются другие решения, в данном случае — Backbone.js и Require.js. А еще Jasmine, Karma и Grunt. Сегодня я поделюсь наброском проекта с применением этих инструментов.

Ссылка для нетерпеливых.

Хотелки

• Прозрачная структура проекта;
• Автоматизация всей рутинной работы;
• Автоматизация тестирования;
• Модульность;
• Повторное использования кода;
• Производительность.

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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