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

В 2007-м Стив Джобс представил iPhone, который произвел революцию в высокотехнологичной индустрии и изменил наш подход к работе и ведению бизнеса. Сейчас 2012-й и все больше и больше сайтов предлагают нативные iOS и Android клиенты для своих сервисов. Между тем не все стартапы обладают финансами для разработки приложений в дополнение к основному продукту. Для увеличения популярности своего продукта эти компании предлагают открытые API, которыми могут воспользоваться сторонние разработчики. Пожалуй Twitter был первым в этой сфере и теперь число компаний, последовавших этой стратегии, растет стремительно. Это действительно отличный способ создать привлекательную экосистему вокруг своего продукта.

Фреймворк для автоматического тестирования веб-приложений на PHP — Codeception живет и развивается. Но в этот раз вместо скупой порции новостей я бы хотел представить вам первый скринкаст в котором показаны азы работы с Codeception. Если вы только читали про Codeception, то вам обязательно стоит взглянуть на него в действии. Ну а если не читали, но у вас есть веб-сайт, который бы вы хотели протестировать — тоже взгляните.

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

Летом 2010 руководство компании в срочном порядке выехало на море в Республику Кипр. Купаясь ночью в теплых Средиземных водах и общаясь много часов подряд, была выработана новая концепция и стратегия, которая оказалась на редкость удачной и верной.

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

У нас выстроилась довольно четкая и простая концепция, по которой мы реорганизовали все.

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

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

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

Хочу поделиться опытом по организации процесса тестирования, который охватывает 3 года моей работы и создание нескольких крупных систем. Описание будет затрагивать только автоматизацию «ручного» тестирования без пересечения с другими аспектами разработки ПО.

Я думаю стоит сразу упомянуть, что на всех этапах мы использовали:

• Модульные тесты с покрытием около 50%
• Continuous Integration с запуском модульных тестов (в последствии и интеграционных), автоматической сборкой и выпуском релиза
• Пересечение из гибких методологий под общим названием ScrumbanXP

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

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

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

Начиная с версии 5.3, PHP позволяет создавать замыкания. К сожалению, пример их использования в официальной документации http://www.php.net/manual/en/functions.anonymous.php#example-163 (example 3) обладает редкой изощрённостью и надуманностью. Надеюсь, пример под катом поможет увидеть в замыканиях другое применение, кроме как с функциями типа array_map().

От переводчика. Автор этой публикации — CEO компании OnSwipe, и бывший СЕО компаний Publictivity.com и Miami Merchants.

Все думают, что быть СЕО стартапа – это гламурная, полная веселья работа.
Я называю это «гламурным мышлением». Речь идёт о жизни стартаперов, которую описывают в прессе. Вы знаете, какие статьи я имею ввиду. Те, которые говорят о том, как легко зарабатывать, как много пользователей компании привлекают, и о том, как это круто — быть СЕО. Очень редко вы услышите, насколько хреново быть CEO, что далеко не каждый стартапер может быть предпринимателем. Оказалось, что основателю проекта для того, чтобы стать успешным СЕО необходимо следовать ряду правил.

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

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

Laconic обеспечивает интуитивный подход к генерированию DOM джаваскриптом. Исходный код Laconic выложен на Гитхабе.

При использовании стандартного DOM API для создания вложенных друг в друга элементов простой таблицы потребовался бы вот какой код:


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

$.el.table(
  $.el.tr(
    $.el.th('first name'),
    $.el.th('last name')),
  $.el.tr(
    $.el.td('Joe'),
    $.el.td('Stelmach'))
).appendTo(document.body);

Laconic добавляет в пространство имён $.el по одному методу для каждого из известных элементов HTML. Этим методам при их запуске передаётся список аргументов, имеющий переменную длину и состоящий из дочерних элементов, строк, чисел, или массивов элементов этих типов. Первым аргументом метода может быть необязательный объект, содержащий атрибуты элемента. Вот пример:

$.el.div({'class' : 'example'}, 
  $.el.div('content'));

Код этого примера создаст такую структуру элементов:

<div class='example'>
  <div>content<div/>
</div>

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

В этой статье мы рассмотрим, как смоделировать структуру, содержащую списки рассылок и данные о людях, которые входят в эти списки.

Здравствуйте программисты начинающие, законченные, а также все сочувствующие. Как известно, ничто не познается так хорошо, как на собственном опыте. Главное, чтобы опыт был полезный. И в продолжении этой простой мысли я хочу предложить заняться несколькими полезными делами сразу:

• Побеседовать на тему «ООП с человеческим лицом».
• Разобраться с прототипами в javascript, коротко и сердито!
• Вспомнить, что «замыкание» это не только ценный мех… удар током.
• Написать на javascript класс Timer — этакий планировщик событий для запуска анимаций, событий, любых функций.
• Весело провести время!

Предупреждение! Если вы не ждете от статьи ничего веселого… то ошибаетесь. Людям с пониженным чувством юмора читать… еще более рекомендуется! Ну-с, приступим…

Совсем недавно у меня появилась задача защитить web-приложение полностью построенное на ajax от CSRF-атак.

Каков же механизм такой атаки? Суть заключается в выполнении запроса с другого сайта под авторизационными данными пользователя. Например, у нас есть действие удаления своего аккаунта example.com/login/dropme. Если защиты от CSRF атаки нет, мы можем на нужном нам сайте разместить тег:

<img src="http://example.com/login/dropme">

Сразу после того как пользователь зайдет на приготовленную нами страницу и подгрузит содержимое img, его аккаунт на example.com будет удален. О защите от этого я расскажу под катом.

В свое время работая в узком кругу программистов, отдельными задачами и даже проектам, мы не задумывались о проблемах связанными с текучкой кадров. Точнее думать — думали, но ни каких мер не применяли, да и в целом коллектив был сплоченный никто не уходил и никого «не уходили». С ростом внутренних проектов и корпоративных клиентов, штат начал разрастаться и казалось, что все отлично — нас больше, значит будем больше успевать и делать, но не тут то было. Мы начали тратить кучу времени на “бесполезные” обсуждения, проверки, излишние проектирование и т.д, больше всего раздражает — это проверка кода. И тут я начал думать, что “мудрые и древние” наверняка решали эти проблемы с сотнями, тысячами программистов, неужели мы не справимся? Я решил провести эксперимент, под названием “автоматизированная проверка стиля кода при комитах”. Для большинства из Вас это не новость и наверняка вы этим пользуетесь, но поделиться опытом внедрения думаю, не будет лишним.

Продолжение этой статьи

Долгое время в ветках SVN был один существенный недостаток. Система не помнила мержей, и программисту приходилось самостоятельно заботиться о том, что бы сохранить номер ревизии, когда происходило копирование изменений из транка. Проблема частично решалась добавлением комментариев в лог, но все таки это было чревато ошибками, и целиком ложилось на совесть программиста.
В версии 1.5, наконец-то, программисты Subversion выполнили свое давнее обещание, и добавили несколько полезных фич для работы с ветками.
Итак, в версии 1.5 команда merge обзавелась двумя новыми опциями: --record-only и --reintegrate.
Теперь ответственность за контроль копирования изменений ложится целиком на плечи SVN (merge tracking), а программист может легко, и без боязни выполнять merge так часто, словно это команда update.

Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

Добрый день!

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

Зачастую начинающие разработчики задают вопроc: «С чего начать создание приложения», какие классы использовать и прочее.

Не стоит воспринимать статью как пример «Hello World» для начинающих изучать язык Java и объектно-ориентированный подход. Предполагается, что читатель уже знаком с языком Java, однако у него возникают вопросы указанные выше.

В этой статье мы даем ответ на эти вопросы.

(Перевод)

Последние несколько лет я провел в изучении и экспериментах со многими языками программирования. В частности, я начал использовать Scala как основной язык, стараюсь использовать функциональный стиль везде где это возможно. Меня также весьма заинтересовал Haskell (чистый функциональный язык) и Clojure (современный диалект Лиспа).

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

Предисловие переводчика
Эта статья продолжает серию переводов официальной документации по PHPUnit на русский язык.
Часть 1, Часть 2, Часть 3,