Доброго времени суток!



В полку Open Source прибыло! Мы (@kulakowka, k12th, dhomich и я) рады представить вашему вниманию перевод официальной документации по Backbone.JS — каркасу для создания RIA приложений на JavaScript, автором которого является Jeremy Askenas — создатель CoffeeScript.

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

Для того чтобы наказать говнокодеров облегчить страдания тех, кто делает ревью кода, можно использовать автоматические средства проверки кода, которые всем давно известны. Это PEAR и PHP Code Sniffer.

Зачем?

Вопрос “Зачем?” — самый главный при принятии любого решения. В нашем случае причин было несколько.

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

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

Но в Mail.Ru Group есть целая команда высококвалифицированных людей, знающих JS, способных самостоятельно написать инструмент, а самое главное — они же им и будут пользоваться.

Во-вторых, задачи. Возьмем проект Почта@Mail.ru. Мы не можем отказаться от шаблонизации на сервере – нам нужна быстрая загрузка при первом входе. Мы не можем отказаться от шаблонизации на клиенте – люди должны видеть высокую скорость реакции на их действия, а значит, обязателен AJAX и шаблонизация на клиенте.

Проблема очевидна: два набора совершенно разных шаблонов на сервере и на клиенте. А самое обидное, что решают они одну и ту же задачу. Дублирование логики нас просто измотало.

v8 — это интерпретатор JavaScript, а значит, мы можем получить один шаблон, который работает как на сервере, так и на клиенте.

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

Документация — одна из самых важных составляющих любого проекта, особенно если этот проект с открытым кодом, который будут читать другие люди. Чтобы сделать мир opensource чуточку лучше, я попытался собрать свои знания в области организации модулей nodejs проектов и сделать такой инструмент как Makedoc!. Ремарка для адептов ruby: это почти то же, что и rdoc.info для руби.

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

В кратце шаблон использования такой: идем на jsdoc.info/[githubusername]/[projectname] и видим готовую документацию по проекту. Либо идем на jsdoc.info/[githubusername] и получаем список проектов для которых можно сгенерировать документацию.

За деталями реализации прошу под кат.

Так исторически сложилось, что домены сайтов называют с префиксом www или без.

Есть несколько взглядов как истинно должен называться домен, прогрессивное человечество считает, что без www — nowww.ru, многие западные эксперты считают обратное.

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

Доброго времени суток!

Наряду со статьей "iPhone: MiTM атака из кармана", родилась почти аналогичная статья про Android.

Мы уже знаем, на что способен iPhone. Уступает ли ему Android?

Было рассмотрено около 25 боевых приложений. Хочу предоставить вам результат маленького исследования. Многие приложения даже не запустились, некоторые подвесили телефон намертво, но некоторые даже работали!

Весь софт тестировался на телефоне LG Optimus, с версией Android 2.3.

Итак, краткий обзор боевого софта на Android:

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Представим, что у нас есть приложение/сайт с достаточно высокой нагрузкой.

Многие разработчики приложений для «ВК» или «Одноклассников» сталкивались с ситуацией, когда приложение выходит в топ новых приложений и на вас сваливается огромнейшая нагрузка.
Допустим, в процессе обращения клиента к серверу, генерируется картинка. Серверов у нас много. Каким образом клиенту отдать эту картинку, если у вас нет единой файловой системы и файлы не синхронизируются между серверами?

Как поступить, когда на сервер ежесекундно приходит большое количество народу? Ответ прост — nginx.

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

Для подобных вещей придумали так называемое тегирование. Т.е. создается какой-то тег, который сохраняется со всеми кешами связанными с данной таблицей. И как только он меняется, все связанные кеши должны перезагрузиться. Как оказалось в Yii это делается очень просто.

Доброго времени суток. Сегодня мне хотелось бы разобрать такую интересную возможность Yii Framework, как валидация данных моделей. На момент написания статьи актуальная версия фреймворка 1.1.10, собственно рассматривать валидацию на ней и будем.
Хочу сразу сказать, что мне не хочется перепечатывать мануалы и API, поэтому я по возможности буду ссылаться на готовые источники. Кроме того, я не буду описывать то, как пользоваться валидаторами. Я постараюсь раскрыть механизм валидации моделей Yii на основе правил валидации, чтобы используя их вы понимали что же на самом деле происходит и где в случае чего можно искать ошибки.

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

Все советы автономны и их порядок не имеет значения.

Канал GTV представляет полную версию документального фильма на русском языке о всемирно известной интернет-энциклопедии Wikipedia.

Связавшись с правообладателем, редакция канала получила право на перевод и бесплатную трансляцию фильма в рунете.

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

Каждый, кто всерьез занимался разработкой на Ruby, знает про замечательный гем Cucumber. Вкратце — это библиотека для автоматизированного тестирования, заточенная под BDD. Подробнее можно почитать в топике хабраюзера dapi, а еще лучше посмотреть подкаст от Райна Бэйтса. Основная прелесть «огурца» состоит в том, что он позволяет писать тесты на понятном человеку языке, и даже не обязательно английском. Выглядит это так:

Feature: Addition 
  In order to avoid silly mistakes 
  As a math idiot 
  I want to be told the sum of two numbers 

  Scenario: Add two numbers 
    Given I have entered 50 into the calculator
      And I have entered 70 into the calculator
     When I press add
     Then The result should be 120 on the scree

Благодаря Cucumber я подсел на BDD на рельсах. Но вот на PHP, с которым приходится работать основную часть времени, отношения с BDD как-то не сложились. И в первую очередь из-за отсутствия достойного инструментария. Но однажды судьба завела меня на страницу библиотеки Behat (написанной, кстати говоря, хабраюзером everzet). И на меня свалилось счастье…

Upd. Если вы знаете, что такое BCrypt, можете дальше не читать. Если вы используете PHP 5.5+ то можете прочитать эту статью. Ниже же я изобрел свой велосипед, рабочий, но с двумя рулями, задний запасной. Молод был, горяч.

Привет, хабр! Сегодня, в процессе разработки системы аутентификации для своего проекта передо мной встал выбор — в каком виде хранить пароли пользователей в базе данных? В голову приходит множество вариантов. Самые очевидные:

• Хранить пароли в БД в открытом виде.
• Использовать обычные хэши crc32, md5, sha1
• Использовать функцию crypt()
• Использовать статическую «соль», конструкции вида md5(md5($pass))
• Использовать уникальную «соль» для каждого пользователя.

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

PHPUnit содержит расширение для тестирования базы данных. Расширение выполняет следующие функции:

• перевод базы данных в заранее известное состояние,
• выполнение необходимых модификаций данных,
• проверка, что в базе данных созданы ожидаемые записи.

К сожалению в этом списке отсутствует одна очень нужная нам фича — восстановление данных в состояние, в котором они находились до тестов. Я хочу предложить 2 варианта решения этой проблемы. Так же попутно остановлюсь на проблеме внешних ключей, которая часто возникает при накатывании не полных тестовых данных на «рабочую» базу.

Итак, я предлагаю 2 варианта решения проблемы: как после проведения юнит теста вернуть базу данных в исходное состояние:
Первый путь — «Транзакционный». Суть которого сводится к выполнению всего теста в рамках одной транзакции, и последующему rollback'у транзакции.
Второй — Перед выполнением теста скопировать структуру «рабочей» базы и проводить тестирование на ней.

Введение

Современные проекты все чаще предъявляют высокие требования к покрытию автоматическими тестами. В наше время писать тесты не просто признак хорошего тона, но одно из требований, которое предъявляется к коду. Все чаще мы слышим такие аббревиатуры, как TDD (Test Driven Development) и BDD (Behaviour Driven Development) и многие строго следуют этим подходам в разработке.
BDD это одна из разновидностей TDD, и об этом я хотел бы написать в этой статье. Точнее не о самом BDD, а о frameworks, которые нам предоставляет индустрия на сегодняшний день. А если уж быть совсем точным, то о трех из них: spock, easyb и cucumber.

При написании одного проекта, возникла необходимость в организации мультиязычности на сайте. Причем количество языков не должно ограничиваться двумя и URL должны быть человеко-понятные и SEO оптимизированные. Тоесть ссылки на сайте должны быть вида:
http://mysupersite.ru/ru/contacts для русского языка
http://mysupersite.ru/en/contacts для английского языка
Так как опыт у меня не очень большой, я начал вопрошать гугл. Вариантов, как оказалось, достаточно много, однако из всех мне приглянулся один вариант, который я использовал и слегка модифицировал.

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

Особо вероятно изобретение велосипеда, когда рост сложности приложения происходит постепенно и в некотором смысле незаметно. Сложное приложение обычно является богатым приложением (rich), его элементы и особенности специфицированы W3C www.w3.org/TR/backplane. Известный JavaScript-евангелист Addy Osmani так дополнительно определяет сложное приложение: “По-моему, крупное JavaScript приложение есть нетривиальное приложение, требующее значительных усилий разработчика для поддержки, причем наиболее сложное оперирование обработкой и отображением данных ложится на браузер” (http://addyosmani.com/largescalejavascript/).

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

Сегодня я хочу рассказать, как в Codeception реализовано юнит-тестирование в BDD-стиле.

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