В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

Впервые css был представлен примерно в 1995 году, и был предназначен для стилизации простых текстовых документов. Не веб сайтов. Не приложений. А именно текстовых документов. С тех пор, css, прошел долгий путь. Возможно слишком долгий.

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

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

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

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

Проблемы git-flow

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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

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

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

Grunt — это инструмент для сборки javascript проектов из командной строки с использованием задач. Релиз вышел совсем недавно, автор Ben «Cowboy» Alman, проект есть на github. В этой статье я рассмотрю основы Grunt, его установку и использование.

UPD

Сегодня в этом уже нет никакого смысла. Просто настройте себе HTTP/2

• Nginx www.digitalocean.com/community/tutorials/how-to-set-up-nginx-with-http-2-support-on-ubuntu-16-04
• Apache httpd.apache.org/docs/2.4/howto/http2.html

Что это?

В один прекрасный день я отчётливо понял, что устал писать длинные ссылки на файлы изображений, каждый раз задавать им ширину и высоту, заботиться о том, чтобы это всё не прыгало при загрузке и не мигало при наведении мышкой. И я решил автоматизировать всю эту рутину. Так появился Bootstrap CSS Sprite — библиотека, которая позволяет работать со всеми вашими изображениями, как с одним спрайтом. При этом доступ к тайлам спрайта осуществляется в стиле Twitter Bootstrap.

Приведу пример: у нас есть файл изображения cat.png. Чтобы показать это изображение надо использовать тег <i>, указав для него CSS-класс img-cat, как мы делаем это в Twitter Bootstrap:

<i class="img-cat"></i>

Присылает нам заказчик (Газпром) свою версию договора.
Понимаем — нашу они не подпишут,
вносим реквизиты и отправляем обратно.
Пропадают на две недели… возвращают протокол разногласий к договору.

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

Во время создания front-end составляющей веб приложения, часто приходится сталкиваться с созданием так называемых hover-эффектов. Когда при наведении указателя мыши на DOM элемент меняется цвет ссылки, размер текста или иконка у пункта меню. С такой технологией, как CSS3 Transition, появилась возможность применять анимационные эффекты для DOM-элементов, без использования javascript-кода. Меня эта возможность сразу заинтересовала и я стал применять ее, без лишних усилий создавая плавные переходы.

При разработке дизайна необходимо учитывать корректность его отображения не только на больших экранах, но и на мобильных устройствах. И в первую очередь это касается читаемости контента. Поэтому необходимо уделять особенное внимание типографике, которая является основой веб-дизайна. На эту тему есть полезная статья шестилетней давности — Web Design is 95% Typography (автор Oliver Reichenstein).

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

В последнее время в IT-сообществе довольно много шумихи вокруг серверного JavaScript, в частности — NodeJS, однако, как это ни странно, оказалось довольно сложно найти информацию о том, как писать модульный, объектный код. Что я имею ввиду? Дело в том, что с js я знаком совсем недавно, до этого писал небольшие приложения на Java, а в свободное время пишу серверную часть онлайн-игры на PHP и, как и следовало ожидать, как и многим начинающим программистам на JS мне было очень непривычно вместо объектно-ориентированного использовать так называемое прототипно-ориентированное программирование. Тем более, JavaScript вносит достаточно много путаницы даже в это дело со своими Object.prototype и __proto__. Первое, что пришло мне в голову, как и многим другим разработчикам — сделать свою реализацию «привычного ООП», сделал. Немного подумав я решил, что это просто незачем, если мы работаем с nodeJS. За мою, хоть и недолгую практику, мне не довелось встретить задачу, которая бы требовала настоящего ОО подхода, я имею ввиду реальную необходимость наследования, полиморфизма и тем более инкапсуляции (конечно, все это нужно, но в той степени, которую js предоставляет).

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


Быстро разбогатеть и уплыть на собственный остров просто, увы, лишь в мечтах.

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

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

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

Внимание! В статье содержатся примеры работы до релизной (до v1.0.0) версии библиотеки.
Скоро выйдет ещё одна статья. Эта только в качестве ознакомления. Всю необходимую для использования библиотеки информацию можно получить в README и комментариях в коде.

Картинка для привлечения внимания:

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

1. Использование системы контроля версий.
2. Грамотное комментирование кода.
3. TDD или хотя бы простое юнит-тестирование кода.

Для первого пришлось освоить азы git, и создать свой первый репозиторий на github. Для второго выбрал JsDoc, из-за которого пришлось перебраться с notepad++ на sublime text (только там был соответствующий плагин).
А вот с третьим, неожиданно для меня, возникли серьёзные трудности.

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

Одна из проблем нашего высшего образования в том, что в вузах учат много чему, и алгоритмам, и языкам программирования, и ООП, и даже паттернам проектирования. Но я еще ни разу не встречал, чтобы в вузах учили работать работу. Лабораторки не в счет. Спихнул – и забыл! Возможно, просто не везло.

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

Итак, про семь навыков…

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

Добрый день, хабровчане!

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

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

Доброго времени суток уважаемые хабравчане. Начну издалека… Share кнопки — это очень важно. Большинство из нас с Вами использует либо стандартные кнопки определенной социальной сети, либо один из этих сервисов: Блок «Поделиться» от Яндекса, AddThis, ShareThis и новоиспеченный Pluso. Если рассматривать все эти способы с точки зрения кастомизации и дизайна, то достойнее всего, на мой взгляд, это реализовали в Pluso. Все остальное почти ничем не отличается друг от друга. Рассматривая основной функционал (непосредственно шаринг), отличается баганутостью только Pluso, где можно легко накрутить счетчики, нажимая кнопки помногу раз. Я не буду сравнивать качество сбора статистики этих сервисов хотя Pluso явно не фаварит, поскольку не компетентен в этом вопросе. Вернемся к кастомизации кнопок. Как таковой, во всяком случае удобной, ее нет. А если говорить про дизайн, то кнопки не адаптированы под Retina дисплеи, что сразу бросается в глаза. Поэтому я решил создать проект на GitHub, который состоит из иконочного шрифта MojoSocial и файла стилей MojoShare.



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

Введение

Firebug добавляет глобальную переменную с именем «console» к каждой веб-странице, загруженной в Firefox. Этот объект содержит много методов, которые возволят Вам писать на консоль Firebug и показывать информацию, проходящую через скрипты.

firebug.ru

К нашему счастью, не только firebug обладает данным функционалом:

• Chrome Javascript console — практически точный аналог
• Opera Dragonfly console — функционал реализован частично
• Firefox Web console — функционал реализован частично

Эта статья — мануал по Console API.
Примеры даны из Chrome 28.0.1500.72 m, Firebug 1.11.3, Firefox 22.0, Opera 12.15 (версия до ухода с presto)

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

На сегодняшний день существует немалое количество обзорных статей о PhoneGap, но к сожалению, написаны они или front-end разработчиками, которые решили заняться мобильными платформами, или нативными программистами, которые решили попробовать себя в кроссплатформенной разработке. И именно с этих позиций рассматриваются достоинства и недостатки PhoneGap'а, возникают статьи о том, «насколько крута кроссплатформа», или об «ущербности кроссплатформенных решений».

В качестве затравки — видео демо-приложения, написанного за 6 часов; готовым был взят UI-бутстрап, наверстанный за 3,5 часа; использовались библиотеки iScroll, backbone, underscore, Jquery, и небольшая обертка на backbone (RAD.js — rapid application development, архитектурный фреймворк, берущий на себя часть оптимизации, связанной с мобильной средой выполнения).


Еще 2 часа было потрачено на фикс движка. Но сегодня речь не о том, что что-то тормозит, дергается, или самописный свайп не всегда вовремя отрабатывает на 14000 объектах данных; речь о том, что на PhoneGap можно и нужно писать.

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