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

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


Итак, каким должен быть безопасный сайт?

Это руководство для WPF-разработчиков, стремящихся добиться максимально чёткой картинки в своих приложениях. Графическая система WPF до мозга костей векторная, но конечным результатом её работы по-прежнему является растр. Если не уделить этому факту должного внимания, можно столкнуться с различными сортами «мыла» — паразитными артефактами растеризации. В такой ситуации важно не терять присутствия духа, причины их возникновения вполне рациональны, а методы борьбы достаточно просты и эффективны.

Привет! У нас сегодня интересная тема – диагностика и мониторинг приложений. Всегда хочется иметь инструмент, который будет (желательно бесплатно, но если нет – то с ценами приемлемыми):

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

Было много прекрасных средств, но я не нашел объединившее бы все функции, и желательно интегрировавшее весь вышеописанный опыт в экосистему, которая уже есть – мою Visual Studio. Если вам интересен такой новый инструмент – Application Insights – с помощью которого можно не только смотреть, но и загружать, например, файлы для IntelliTrace – велком под кат. Уточняю – это не мегагайд о том, «как сделать», это обзор, поэтому будет много ярких картинок.

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

Спросите, какое это имеет отношение к ИТ? Самое непосредственное. Успех управления по KPI зависит не только от того, ЧТО измеряется, но и КАК это делается. Качественные (не количественные) KPI, основанные на субъективной оценке руководителя и ручном вводе результатов «похоронили» не один проект внедрения KPI. Простота и технологичность измерения KPI — абсолютно необходимые условия успеха, и они обеспечиваются только внедрением ИТ. Сегодня ИТ в ритейле – это, как правило, только кассовые и учетные системы. Единственный показатель (KPI), который они позволяют получать автоматически – это выручка. Поэтому управление эффективностью продавцов чаще всего, сводится к выгрузке информации о выручке в MS Excel.

Привет %username%! У нас отличные новости: вышла официальная версия NinjaMock — онлайн-сервиса для создания прототипов. Теперь ты можешь рисовать отличные прототипы веб- и мобильных приложений совершенно бесплатно!

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

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

Идея создания архивов на сервисах вроде Dropbox, Ubuntu One, Яндекс Диск, Диск Google и др. уже давно притягивала мое внимание. Десятки гигабайт бесплатного места, которое теоретически можно использовать для резервирования данных.

Теперь эта идея получила мое первое воплощение. В качестве сервиса для создания архивов был выбран Яндекс Диск.

Эта статья в первую очередь пригодится тем, кто использует тот же стек технологий, что и наша команда, а именно: ASP.NET, C#, NUnit, Selenium 2, git, MSBuild. Будут рассмотрены такие задачи, как интеграция с git, сборка C#-проектов, NUnit-тесты (как модульные, так и тесты UI), а также деплой на сервер. Впрочем, наверняка найдётся интересное и для других пользователей, кроме разве что съевших на этом вопросе собаку. Но они опять же смогут обратить внимание на ошибки в статье или что-то посоветовать: например, как оптимизировать фазу деплоя.

Многие знают, что одно из первых, что говорят в техническом ВУЗе — забыть все, что проходили в школе. Данная рекомендация актуальна и здесь. Полезно иногда с чистого листа начать.

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

Задача каждого торгового алгоритма всегда одна и та же — принести денег владельцу. Алгоритм тем лучше, чем больше денег он в состоянии принести.

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

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

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

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

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

Расчет себестоимости

Говоря о стоимости создания сайта, начать необходимо с определения его внутренней себестоимости в самой компании. До сих пор многие студии работают по фиксированным тарифам (сайт-визитка – XXX рублей, интернет-магазин – YYY и т.п.). Но, так или иначе, все агентства продают время своих сотрудников, и определение себестоимости должно отталкиваться именно от этого фактора.

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

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

• ФОТ сотрудников – 50%
• — Производящие ресурсы (30%)
• — Менеджеры, обслуживающий и административный персонал (20%)
• Условно-постоянные расходы – аренда офиса, канцелярка, расходники, еда, техника и пр. – 15%
• Налоги – 20%
• Маркетинг и реклама – 15%

Web-дизайн находится в постоянном движении: с каждым годом он развивается и видоизменяется под воздействием всевозможных факторов, обрастая новыми интересными инструментами и оставляя позади все старое и неактуальное. Нынешний год можно охарактеризовать тем, что одной из причин развития дизайна становится все большее распространение мобильных устройств и планшетов, появление HTML 5. Но давайте подробнее остановимся на тенденциях web-дизайна в 2013 году.

Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.

Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.

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

Игорь Шойфот — основатель, сооснователь, председатель, СЕО и СОО нескольких успешных стартапов (Epsylon Games, Fotki.com, vInternship, и еще более десятка), инвестор, представитель TMT Investments в Америке (с офисом в Сан-Франциско), преподаватель Университета Беркли (один из самых престижных государственных университетов США) и Университета Сан-Франциско, председатель совета директоров крупнейшего украинского инкубатора Happy Farm. Игорь и TMT Investments специализируются на инвестициях (от 250 тысяч $ до 5 миллионов) в продвинутые стартапы, а также помогают стартапам из СНГ и России выйти на международные рынки. Если вы из России или СНГ и приезжали в Долину для поиска инвестиций или бывали на каких-нибудь стартаперских вечеринках, то вы наверняка уже знакомы с Игорем.

Интервью получилось довольно провокационным и длинным, поэтому назвали его в шутку «Анатомия Игоря Шойфота» — типа «всё, что вы хотели, но боялись у Шойфота спросить». Кстати, кто не знает Игоря, предыдущее ознакомительное интервью (не моё) на Хабре было тут, а здесь отличная обучалка от Игоря о том, как делать питч-презентацию

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

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

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

Вы неплохо владеете языком C# и платформой .NET в целом? Вам надоело стоять в стороне и смотреть, как кто-то другой пишет крутые мобильные приложения вместо вас? У меня есть для вас кое-что интересное! То, что поможет вам изменить сложившуюся ситуацию и позволит писать отличные мобильные приложения, не требуя отдельного изучения Objective-C и Java. Я расскажу вам о продукте Xamarin. Подробно и правдиво.

Что это?

Xamarin — это фреймворк для кроссплатформенной разработки мобильных приложений (iOS, Android, Windows Phone) с использованием языка C#. Идея очень простая. Вы пишете код на своем любимом языке, с применением всех привычных для вас языковых фич типо LINQ, лямбда-выражений, Generic`ов и async`ов. При этом вы имеете полный доступ ко всем возможностям SDK платформы и родному механизму создания UI, получая на выходе приложение, которое, строго говоря, ничем не отличается от нативных и (по крайней мере по заверениям) не уступает им в производительности.

Фреймворк состоит из нескольких основных частей:

Некоторое время назад в компании, где я работаю в связи с расширением комманды было принято решение о введении процесса code review. Выбор инструмента пал на Review Board — продукт обладает достаточным функционалом, активно разрабатывается с 2006 года и является open source. В качестве системы контроля версий у нас используется Mercurial

О том, с чем какими задачами столкнулись при организации процесса код ревью для связки Review Board + Mercurial — под катом.

Успеваете ли вы делать всё, что планируете? Храните ли сотни невыполненных задачек пылящимися на полке, или решаете одну за одной? Чувствуете ли вы в целом удовлетворение в достижении своих желаний (и неважно каких, рабочих или личных)?

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

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

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

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой