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

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

Велосипед

Итак, Вася долго трудился рядовым программистом, ведущим программистом и наконец стал Руководителем. У него есть команда отчаянных головорезов разработчиков в количестве двух единиц. Безусловно талантливых и знающих свое дело специалистов.

Вася получает первый заказ — надо сделать … велосипед.

Нельзя просто так взять и рассказать про progressive enhancement, не упомянув о graceful degradation. В чем же разница между этими понятиями? Как уже говорилось в более ранней статье, graceful degradation можно перевести, как отказоустойчивость. Это очень широкое понятие, но в контексте веба его можно понимать как отказоустойчивость клиентских веб-интерфейсов, серверной части сайтов и так далее. В этой статье graceful degradation будет пониматься как отказоустойчивость клиентских веб-интерфейсов.

Graceful degradation может выражаться в возможности работы при отключенном JavaScript, в достаточно аккуратном отображении интерфейса в браузере, не поддерживающем новые свойства CSS3, в адекватном отображении сайта при отключенных изображениях. В каждом из этих случаев работа пользователя с интерфейсом будет в принципе возможна, хотя и не так удобна.

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

На самые популярные и важные вопросы дизайнер нового интерфейса Анна Котляревская ответила в интервью:



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

Итак, в чем проблема обычных способов переключения раскладки? То, что они сделаны по остаточному принципу — нужен был способ переключения, а 101-клавишная клавиатура уже была стандартом. Для англоговорящих проблем, конечно, нет. А вот всем остальным пришлось выучить Shift-Ctrl.
Когда есть возможность не соблюдать стандарты, проблемы нет — добавляем кнопку РУС-ЛАТ, и проблема решена:

А как быть остальным?

В последнее время мои коллеги начинают знакомство с git'ом. И один из интересующих их вопросов — как откатиться до определённой ревизии. В интернете можно найти набор команд, но хочется, чтобы было понимание каждой из них. Баловство с комадами git'а без понимания может привести к потере истории разработки.

В этой статье я хочу рассказать о командах git checkout и git reset с ключами --soft и --hard.

Совсем недавно мы отрелизили на hh.ru зарплатные кластеры, которые помогают оценить свою стоимость как специалиста. Это достаточно интересная и гибкая фича, такая, что с ее помощью даже можно провести небольшое исследование рынка труда, определив своё место в нем:

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

Тогда в качестве шаблонизатора мы использовали XSL, а данные передавали в формате XML. Переведя проект на новый интерфейс, мы начали искать другие способы ускорения работы интерфейса Яндекс.Почты.

Недавно мы перевели всю Почту на JS-шаблонизатор и JSON-данные.

Не очень строгий перевод материала mrbook.org/tutorials/make Мне в свое время очень не хватило подобной методички для понимания базовых вещей о make. Думаю, будет хоть кому-нибудь интересно. Хотя эта технология и отмирает, но все равно используется в очень многих проектах. Кармы на хаб «Переводы» не хватило, как только появится возможность — добавлю и туда. Добавил в Переводы. Если есть ошибки в оформлении, то прошу указать на них. Буду исправлять.

Статья будет интересная прежде всего изучающим программирование на C/C++ в UNIX-подобных системах от самых корней, без использования IDE.

Компилировать проект ручками — занятие весьма утомительное, особенно когда исходных файлов становится больше одного, и для каждого из них надо каждый раз набивать команды компиляции и линковки. Но не все так плохо. Сейчас мы будем учиться создавать и использовать Мейкфайлы. Makefile — это набор инструкций для программы make, которая помогает собирать программный проект буквально в одно касание.

Комманда git up (аналог svn up) добавляется так:

git config --global alias.up '!(git add . && git stash && git pull --rebase >&2) | grep -v "No local changes to save" && git stash pop'

git up при надобности ныкает все ещё незакоммиченные изменения в stash, обновляет локальную ветку до свежайшей и восстанавливает локальные изменения назад. В том числе переносит ещё неотправленные локальные коммиты в самый конец, делая историю линейной как в Subversion, т.е. избегая лишних веток и merge-коммитов.

Предисловие

Дэниел Клиффорд сделал на Google I/O прекрасный доклад, посвященный особенностям оптимизации кода JavaSсript для движка V8. Дэниел призвал нас стремиться к большей скорости, тщательно анализировать отличия между С++ и JavaScript, и писать код, помня о том, как работает интерпретатор. Я собрал в этой статье резюме самых главных моментов выступления Дэниела, и буду обновлять её по мере того, как движок будет меняться.

Хочу поделиться набором ссылок на нексолько полезных, интересных и, возможно, не самых известных материалов по JavaScript. Из них вы узнаете немного больше об истории появления языка, о его настоящем, тонкостях реализации в различных браузерах, и о будущем развития стандарта ECMAScript. О различных способах наследования в том числе об эмуляции «классического» ООП, множественном наследовании и миксинах. О функциональном стиле программирования в JavaScript: чистые функции, map, reduce, частичное применение и композиции функций. И, наконец, что если бы Хемингуэй писал на JavaScript?

В Интернет можно найти множество различающихся реализаций и схем, уже набившего оскомину, паттерна MVC. В разных книгах я также встречал разные схемы. Это порождает некоторую путаницу и комментарии к моей предыдущей статье: "Реализация MVC паттерна на примере создания сайта-визитки на PHP" тому подтверждение. В поисках истины, я попытался расставить все по местам… перечитал некоторую литературу и статьи по паттернам проектирования и написал дополнение к упомянутой статье. Но решил запостить это дополнение, как отдельный топик в надежде на фидбэк. Под катом вы найдете несколько часто встречающихся схем MVC и MVP с описанием жизненного цикла приложения, а также описание менее популярных паттернов HMVC и MVVM. Разумеется, некоторые из перечисленных паттернов применимы не только к веб-приложениям, но в статье они рассматриваются именно в этом контексте.

Composer (getcomposer.org) — это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer — это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

При создании Composer авторы черпали идеи и вдохновение из аналогичных проектов: npm для Node.js и Bundler для Ruby.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano, сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github.

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2). Список проектов использующих Composer можно посмотреть на сайте packagist.org — это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Почти год назад я опубликовал статью о микрофреймворке под названием 'fat-free', написанном на PHP. Тогда этот фреймворк и сама статья вызвали некоторый интерес, поэтому я решил сделать обзор еще одного PHP микрофреймворка в стиле популярного Sinatra — Silex project.

Созданный в известной в РНР кругах Sensio Labs, не менее известным Fabien Potencier — автором одного из самых популярных на сегодня PHP фреймворков — Symfony, Silex является облегченной версией ожидаемого армией фанатов (к которым осмелюсь отнести и себя) Symfony2.

Для своей работы Silex использует ключевые компоненты Symfony2 в связке с несложной реализацией шаблона проектирования “Внедрение зависимостей” в виде сервис-контейнера Pimple, который позволяет максимально просто отделить логические части кода друг от друга — сделать их независимыми.

Как и у Symfony2 — у Silex интуитивно понятный API, что делает процесс разработки достаточно приятным и позволяет практически в несколько шагов добавлять свой функционал в сам фреймворк.

Не так давно на Хабре была статья про навороченный стартап, заточенный на сбор ошибок JavaScript. Далеко не всегда нужно столько возможностей, но оказалось, что многие просто не знают про старый бородатый способ с Google Analytics. Про него я и попытаюсь кратенько рассказать.

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)

5 месяцев, 26 дней и сколько-то часов прошло с момента коммита в git первых строчек кода Футубры. Столько времени у нас ушло, чтобы собрать команду, провести ряд исследований, проработать концепцию и реализовать проект, который сделает жизнь людей интереснее.

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

Первый пост хочется посвятить самому важному – базовым принципам, на которых строится Футубра:

• progressive enhancement
• mobile first
• responsive web design

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

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

Cуществует уже несколько десятков JavaScript-фреймворков для построения сложных приложений в браузере. Чтобы сравнить их между собой и выбрать наиболее подходящий, примитивного примера вроде классического «Hello, world» явно недостаточно. Более сложные и реалистичные примеры программ в книгах и документации каждого фреймворка могут сильно отличаться, и сравнивать их между собой затруднительно. Проект TodoMVC решает именно эту проблему. Это набор примеров реализации одного и того же простого, но вполне законченного веб-приложения с использованием разных фреймворков + эталонный пример на чистом JavaScript.

Приложение TodoMVC — это список дел. Дела можно добавлять, помечать как выполненные и удалять. Список должен сохраняться в локальном хранилище браузера. Приложение должно по возможности использовать стандартный шаблон HTML и CSS. Вот подробная спецификация приложения.

Всем привет! Меня зовут Сергей Константинов, и я руководитель группы разработки алгоритмов API Яндекс.Карт.

Сегодня мы запустили новую версию JavaScript API — 2.0. Вообще, в этом месте должна быть перепечатка поста из блога Яндекса, но мы решили в этот раз отступить от традиции :).

Вместо сухого официального сообщения, я попробую в тёплой ламповой обстановке рассказать вам, как и зачем мы делали JavaScript API 2.0.