Буквально несколько часов назад на HTML5 Rocks появилась замечательная статья о текущем положении дел, касающихся загрузки скриптов на странице. Представляю вашему вниманию ее перевод. Поправки можете присылать в личные сообщения :)
Читать полностью »
Рубрика «переводы» - 29
Погружение в темные воды загрузки скриптов
2013-06-06 в 6:31, admin, рубрики: javascript, JS, script, Веб-разработка, всё плохо, перевод, переводыУлучшаем тестирование путем использования реального трафика
2013-06-05 в 8:19, admin, рубрики: production, staging, testing, переводы, тестирование TL;DR Чем ближе к реальности ваши тестовые данные, тем лучше. Попробуйте Gor — автоматическое перенаправление production трафика на тестовую площадку в реальном времени.
Здесь в Granify мы обрабатываем огромное количество генерируемых пользователями данных, наш бизнес построен на этом. Мы должны быть уверены что данные собираются и обрабатываются правильно.
Вы даже не представляете насколько странными могут быть данные пришедшие от пользователей. Источником могут быть прокси-серверы, браузеры о которых вы никогда не слышали, ошибки на клиентской стороне, и так далее.
Читать полностью »
Перевод статьи Аллана О’Доннелла Learning C with GDB.
На фоне таких высокоуровневых языков, как Ruby, Scheme или Haskell, изучение C может оказаться настоящим испытанием. В придачу к преодолению высокоуровневых особенностей C, таких как ручное управление памятью и указатели, вы еще должны обходиться без REPL. Как только Вы привыкнете к исследующему программированию в REPL, иметь дело с циклом написал-скомпилировал-запустил будет для Вас небольшим разочарованием.
С недавнего времени, мне пришла в голову идея, что я мог бы использовать GDB как псевдо-REPL для C. Я немного поэкспериментировал, используя GDB как инструмент для изучения языка, а не просто отладки С, и это принесло мне много веселья.
Читать полностью »
FeatureBranch
2013-06-03 в 8:35, admin, рубрики: branching, continuous integration, Git, merge conflict, VCS, переводыС распространением распределенных систем управления версиями (DVCS), таких как Git и Mercutial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.
Основная идея feature branch заключается в создании нового брэнча когда вы начинаете работать над какой либо функциональностью. В DVCS вы делаете это в своем собственном репозитории, но те же принципы работают и в централизованных VCS.
Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).
Нижний предел для CAPTCHA, Белый дом
2013-06-02 в 20:14, admin, рубрики: accessibility, captcha, Белый дом, Веб-разработка, доступность, переводы, метки: accessibility, captcha, Белый дом, доступностьНевероятно и стыдно. Является ли это новым падением CAPTCHA, да к тому же для Белого дома? Позвольте мне объяснить.
Для того, чтобы подписать on-line петицию к Белому дому об обеспечении глобальной доступности книг для слепых, нужно зарегистрировать аккаунт. Проблема в том, что для этой регистрации обязательно нужно решить CAPTCHA, а её аудиоверсия не поддаётся расшифровки. Таким образом, слепые люди не могут подписать петицию, отстаивающую равноправие для слепых!
Читать полностью »
Мой профиль vs Ваши настройки: размышления о том, как интерфейс должен общаться с пользователем
2013-06-01 в 16:33, admin, рубрики: ui/ux дизайн, дизайн интерфейсов, интерфейс, интерфейс пользователя, интерфейсы, переводы, Песочница, метки: ui/ux дизайн, дизайн интерфейсов, интерфейс, интерфейс пользователя Здравствуйте.
Перед вами перевод статьи Дастина Кертиса (Dustin Curtis) «Yours vs. Mine», которую он опубликовал в собственном блоге. Сразу скажу, что перевод достаточно вольный: старался изложить понятно, в ущерб формальной точности. Статья не претендует на статус научного исследования, и содержит краткое резюме двух концепций взаимодействия с пользователем. Все ссылки на другие источники мои, как и замечания в скобках.
Об авторе: Дастин Кертис — UI/UX дизайнер, создатель блог-платформы Svbtle. Из известных его работ — редизайн сайта American Airlines. Подробней тут.
Мой vs Ваш
При разработке дизайна нового приложения довольно рано встает следующий вопрос. Как интерфейс должен называть пользовательские данные: «мои» или «ваши»? То есть, «мой профиль» или «ваши настройки»? Меня долго гложил этот вопрос. Так какой вариант правильный?
Энерджи-менеджмент (управление энергией)
2013-06-01 в 11:47, admin, рубрики: gtd, переводы, тайм-менеджмент От переводчика. Предлагаю вашему вниманию статью Скотта Янга с одноименного блога. Я решил оставить термин «энерджи-менеджмент» без перевода, поскольку существенной мыслью автора является противопоставление его тайм-менеджменту.
Приятного чтения!
Моё первое знакомство с коллегой-блоггером по имени Phil Gerbyshak состоялось, когда я опубликовал весьма подробный комментарий о том, что воспринимаю энерджи-менеджмент (управление энергией) и тайм-менеджмент (управление временем) как независимые друг от друга вещи, обе из которых следует использовать полноценно. Я также дал понять, что склонен считать подход тайм-менеджмента превосходящим энерджи-менеджмент по части пиковой производительности.
Я был неправ. Признаю это. Должен сказать, я тогда потихоньку перемещался в лагерь тех, кто считает обязательное планирование времени и расстановку приоритетов критическим фактором общей производительности и эффективности. Тайм-менеджмент становился набирающей популярность областью со множеством различных техник, цель которых была помощь в упорядочении времени таким способом, чтобы выкладываться на все сто процентов. Тщательная организация своих целей, задач и приоритетов дает здесь возможность спланировать свой день максимально эффективно.
К несчастью, в реальности это работает не совсем так. Хоть тщательная организация приоритетов и планирование времени производило ощутимый эффект, меня все еще грызло чувство, что мой реальный день никогда вполне не оправдывает те надежды, которые я возлагал на него предыдущей ночью. Казалось, какое-то особое влияние, какая-то сила, не поддающаяся осознанию, воздействует на мой предстоящий день. Сейчас я разобрался, что это была за сила. Это была энергия.
Читать полностью »
Вы опасно некомпетентны в криптографии
2013-05-29 в 13:24, admin, рубрики: hmac, md5, аутентификация, криптография, переводы, уязвимости, метки: hmac, MD5, аутентификация, криптография, уязвимости От переводчика: Хоть посыл статьи Ali Najaf, переведённой ниже, и носит слегка рекламный оттенок («оставьте криптографию нам, экспертам»), но описанные в ней примеры показались мне довольно интересными и заслуживающими внимания.
Кроме того, никогда не будет лишним повторить прописную истину: не придумывайте свою крипто-защиту. И эта статья отлично иллюстрирует почему.
Читать полностью »
Статические члены класса. Не дай им загубить твой код
2013-05-28 в 7:08, admin, рубрики: php, static, ооп, переводыДавно хотел написать на эту тему. Первым толчком послужила статья Miško Hevery "Static Methods are Death to Testability". Я написал ответную статью, но так и не опубликовал ее. А вот недавно увидел нечто, что можно назвать «Классо-Ориентированное Программирование». Это освежило мой интерес к теме и вот результат.
«Классо-Ориентированое Программирование» — это когда используются классы, состоящие только из статических методов и свойств, а экземпляр класса никогда не создается. В этой статье я буду говорить о том, что:
- это не дает никаких преимуществ по сравнению с процедурным программированием
- не стоит отказываться от объектов
- наличие статических членов класса != смерть тестам
Хотя эта статья про PHP, концепции применимы и к другим языкам.
Читать полностью »
Когда полиморфизм терпит неудачу
2013-05-27 в 8:41, admin, рубрики: перевод, переводы, Песочница, Программирование, метки: перевод, Программирование Большинство фанатов ООП одновременно являются и фанатами полиморфизма. Многие хорошие в других отношениях книги (например, «Рефакторинг» Фаулера) впадают в крайность, утверждая, что если вы используете проверки типов во время выполнения (такие как операция instanceof в Java), то вы, по всей вероятности, в душе злодейский злодей из тех, что пугают маленьких детей операторами switch.
Вообще говоря, я согласен с тем, что использование instanceof и его аналогов обычно является признаком недостаточных навыков ООП проектирования. Полиморфизм лучше проверок типов, он делает код гибче и понятнее. Однако, по крайней мере в одном случае, достаточно распространенном чтобы считаться паттерном сам по себе, вы просто не можете использовать полиморфизм. Я бы применил его с удовольствием, честно, и если вы знаете как это сделать – расскажите мне. Но не думаю что это возможно, особенно в статических языках типа Java или C++.
Определение полиморфизма
На тот случай если вы незнакомы с терминологией ООП, полиморфизм – это претенциозное обозначение для концепции позднего связывания. Позднее связывание – это претенциозное обозначение (вы обнаружите здесь паттерн если копнете глубже) для отсрочки решения о том какой метод будет вызван до начала выполнения программы. Когда и будет выполнена проверка соответствия объекта и сообщения (метода).
В языках программирования, ориентированных на производительность, таких как C++, Java или OCaml, методам ставятся в соответствие числа, а для каждого класса заводится таблица его методов, по которой и производится поиск во время выполнения. В языках же отдающих предпочтение гибкости и динамизму, поиск осуществляется с использованием хэширования названий методов. В остальном эти два подхода практически совпадают.
Виртуальные методы сами по себе не создают полиморфизм. Он вступает в игру только когда у заданного класса появляются несколько подклассов, каждый из которых реализует свою особую версию полиморфного метода. В банальнейшем примере из учебника это иллюстрируется тем, что в зоопарке все животные по-разному обрабатывают сообщение неприятноПахнуть(). Хотя на самом деле, конечно, по моему скромному мнению, все они чертовски схожи, дело просто в величине. Правда, я все еще не решил победит ли гиппопотам жирафа, спросите меня об этом немного позднее.