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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:

Потому что на десять сеньоров по статистике девять тупят.

Полгода назад я делал перевод статьи на Хабре Подробно о свойстве float. В этот раз взглянем на него немного под другим углом. При разработке сайта мы часто используем float'ы для позиционирования некоторых блоков на странице, например сайдабара. Но так ли это необходимо?

Float не всегда удобен: например при верстке сетки с изображением. Иногда уместно применять inline-block, который имитирует поведение float'а.

Что такое inline-block?

Обычная структура блочного элемента:



Inline-block — это значение, которые можно назначить свойству display. Название происходит от некоторых характеристик как строчного, так и блочного элементов.

Французский разработчик Julian Garnier представил реализацию шахмат в 3D с использованием HTML/CSS3/JS, причем вся 3D-анимация выполнена с помощью CSS3.

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

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

HTML разметка

Создаем два блока с атрибутами "data-type" и "data-speed":

<section id="home" data-type="background" data-speed="10" class="pages">
         <article>Простая техника Parallax Scrolling</article>
</section>
<section id="about" data-type="background" data-speed="10" class="pages">
         <article>Простая техника Parallax Scrolling</article>
</section>

Для управления значениями скорости и позиции в JavaScript, data-type используются как ключевые атрибуты при передачи необходимых параметров.

Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.

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

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

При создании мобильного приложения под iPad для одной крупной компании перед нами встал вопрос — как распространять данное приложение. Самый распространённый вариант — конечно, через AppStore.

Но данный вариант нам не подошел, так как приложение создавалось для работников компании, а не для общего пользования. Остался только второй вариант — Enterprise Program (подробнее о Developer Program и Enterprise Program).

Клиент купил лицензию, мы занимались разработкой, и вот настало время выкладывать приложение. До этого мы выкладывали приложения в AppStore, а вот опыта работы с in-house приложениями (они предполагают внутреннее использование в компании и не предназначены для выкладывания в общий доступ) не было. К нашему удивлению, мы не нашли полноценных статей, описывающих данный процесс, поэтому решили составить некую инструкцию, которая поможет сэкономить кому-то время.

В первой части я рассказал, как программисту относительно просто запустить с нуля свой личный сайт с использованием Github, Heroku и Twitter Bootstrap.

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

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

Воспроизведение кешированного аудио в оффлайн режиме в Safari под iOS долгое время было настоящим испытанием, которое было признано недостижимой целью. Но с приходом веб аудио API (только в движках WebKit), это наконец-то стало возможным, несмотря на то, что вам все-равно придется сделать несколько шагов.

Плохая новость в том, что вы все равно не сможете кешировать mp3 файлы, используя кеш приложения и просто загружать их используя XmlHttpRequest. Safari под iOS 6 будет кешировать mp3 файлы, но потом молча откажется воспроизводить их (очень полезно!)

Это совсем краткий пост о причинах возникновения Deadlock

В более менее нагруженных проектах, использующих транзакции InnoDB, в любой момент может возникнуть ошибка вида

«Deadlock found when trying to get lock; try restarting transaction»

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

Как сказал однажды известный писатель, «…когда-то и электрическую лампочку считали чудом, а за обычные очки на носу могли запросто cжечь на костре…». Человечество во многом инертно и консервативно в своих взглядах. Люди не сразу воспринимает новое, как известно, первые два производителя молний для одежды разорились. И привычные сейчас вещи иногда проходят несколько витков по спирали прежде, чем превращаются в обычную для нас часть быта. То же самое можно сказать и про технологии.

Поговорим про модную сегодня тему, про так называемые, программно определяемые сети (Software Defined Networks, SDN), которая, как мне кажется, уже прошла все предварительные стадии и готова в ближайшем будущем превратиться в настоящий main stream развития сетей.

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

Совсем недавно проект «Рейтинг Рунета» опубликовал неудивительную и оттого ещё более печальную статистику об оформлении отношений между заказчиком и веб-студией.

Шокирующие факты:

• 17,5% процентов всех сайтов (и более 30% сайтов дешевле 100 000 рублей) делается вообще без всяких договоров.
• Более 26% сайтов дешевле 300 000 рублей делается с формальным договором, служащим лишь основанием для перечисления денег.
• Более 60% сайтов дешевле 100 000 рублей делается без техзадания или по техзаданию клиента.

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

Мир разработчиков программного обеспечения разделен на два лагеря. Знатоки языков поют дифирамбы мощи высокоуровневого программирования — функциям высшего порядка, метапрограммированию, аспектно-ориентированному программированию, рефлексии и т.д. Знатоки инструментов имеют хорошие навыки использования утилит для сборки и отладки, документирования и автодополнения, рефакторинга и тестирования. Знатоки языков склоняются к использованию для разработки текстовых редакторов типа emacs, vim или подобных — они хорошо подходят для почти любых языков, включая новые. Знатоки инструментов выбирают IDE, такие как Visual Studio, Eclipse, или IntelliJ, включающих в себя целые наборы специализированных средств разработки.



Новые языки программирования, такие, к примеру, как Laszlo или Groovy, и новые расширения языков, такие как AOP, обычно доступны только для использования средствами универсального текстового редактора, пока не получат полноценную поддержку в какой-нибудь IDE. Спустя какое-то время, если язык действительно «выстрелил», эта поддержка, несомненно, появится. Это происходит не потому, что сделать нужный инструментарий слишком сложно. Это происходит потому, что вложение усилий в разработку языка и вложение усилий в разработку средств для него находятся в несколько ортогональных плоскостях и порой даже вытесняют друг друга. И вот почему.

Вступление

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

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

Пример первый:
Мне нужен компонент, давно разработанный и протестированный в другом отделе. Подхожу к разработчику. Завязывается диалог:
— Вот мне нужна вот эта штука. Как мне ее использовать в своем проекте?
— Да, вот нужно залить проект из CVS вот по этой метке. Скомпилить. Получится либа, и вот с ней нужно линковаться.
— Ок, спасибо.
Выкачиваешь проект. Компилишь. Вылезает куча ошибок, не хватает каких-то инклудов. Начинаешь выяснять. Оказывается для сборки проекта надо выкачать из CVS еще кучу проектов, их тоже собрать. Некоторые собираются стандартно студией, некоторые с бубном, вроде autoconf, make и иже с ними. Все. Собралось. Начинаются проблемы с линковкой. Не линкуется одно, второе, третье. Сторонних библиотек не хватает. В итоге — куча потерянного времени на непроизводительный труд и вникание в использованные библиотеки, сторонние компоненты и технологии.

Начав писать комментарий к посту «Гадание на кофейной гуще, или каким будет IT через 5 лет?», я понял, что пришло время написать отдельный пост о своих взглядах на будущее ИТ.

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

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

Например, 2007-12 гг. — это время массового распространения социальных сетей и бурного роста всевозможных стартапов, практического утверждения в период кризиса идеи о том, что ИТ и инновации вообще — это будущее, что множество планктоноподобных направлений будет избавляться от персонала, а ИТ прирастать. (Отрицательной стороной этого стало появление инвесторов-дилетантов, не особо разбирающихся в сути конкретного ИТ-проекта и потому по ходу раздувающих пузыри.)

Также это время стремительного вторжения на рынок мобильных платформ, бизнес-инфраструктуры, позволяющей разработчикам под телефоны и планшеты легко продвигать свое ПО и зарабатывать на его продаже плюс оплата внутри приложений и т. д… А также разрабатывать мобильное ПО в качестве клиента к веб-проектам, в результате чего многие веб-проекты уже не сводятся к одному только вебу (и этот тренд приобретает новые качества, о чем будет далее).

Долгосрочные прогнозы сейчас не работают.

Когда я писал свою первую программу на МК-61 в 1992ом, Assembler боролся с машинными кодами. Никаких БД и веба. Когда я получал свою первую айтишную зарплату в 1999ом, я не ожидал, что средняя зарплата увеличится в 10+ раз. На первом месте работы не было даже понятия багтрекера и репозитария, а сейчас — это норма жизни.

Когда я учился на инженера-программиста, я не ожидал, что стану менеджером и увлекусь проектом «Психология в IT». Возможно, вы даже читали на хабре статьи из этого проекта о работе с Групповыми Сопротивлениями (привлечение внимания, борьба за власть, месть, беспомощность) или о последовательности Отрицание-Гнев-Торг-Депрессия-Принятие.

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

Редко в московском офисе Яндекса в 10 утра бывает столько разработчиков, сколько их было утром субботы 24 ноября. И это был не очередной Я.Субботник, как вы могли подумать, а встреча Web Standards Days. В этот раз её совместными усилиями организовали Яндекс и объединение разработчиков «Веб-стандарты» при поддержке W3C.

Мы поговорили с организаторами WSD и некоторыми докладчиками, в том числе представляющими W3C. Они рассказали о том, как появилось мероприятие, какие задачи оно призвано решать и над чем они сами сейчас работают.



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

В этой заметке расскажу о своем опыте юнит-тестирования JS-кода, опыте использования среды выполнения тестов js-test-driver, ее возможности code coverage и скручивании ежа с ужом, а именно данных о code coverage от js-test-driver и генератора отчетов о покрытии PHP_CodeCоverage. Расскажу и покажу как получить вот такие отчеты о покрытии кода...