Небольшое предисловие

Меня всегда интересовала история появлений научных понятий. Перед изучающим новый предмет сначала встает череда безликих определений. Некоторые из них таковыми и остаются, другие привлекают внимание и со временем вырастают в полноценные объекты «картины мира». В качестве недоступного идеала такого стремления можно привести высказывание Литлвуда о Рамануджане:

каждое натуральное число было его лучшим другом

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

Далее будет приведено небольшое исследование подобного рода, объектом которого является понятие регулярного выражения.

2012 год. 17 января.
— Ну что, я публикую.
— Уверен? Мы же раскрываем все секреты.
— Мне кажется, мы научились кое-чему за этот год. Почему бы не рассказать об этом. Мне кажется это что-то новое в отрасли. Мне хочется этим поделиться…

Речь в этой короткой переписке идет про статью «12000 рублей за сайт, есть ли бизнес за МКАДом», которую мы опубликовали ровно год и месяц назад. После публикации статьи на «хабре», количество заявок на разработку сайта увеличилось вдвое и не снизилось по сегодняшний день. Весь год мы работали, как сумасшедшие, оптимизируя производство, дорабатывая функционал типовых решений, экспериментировали с моделью управления проектами, трудились над программной платформой, выступали на конференциях. Сказать, что нам было непросто, это ничего не сказать. Что у нас получилось?

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

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

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

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

Moq – это простой и легковесный изоляционный фреймврк (Isolation Framework), который построен на основе анонимных методов и деревьев выражений. Для создания моков он использует кодогенерацию, поэтому позволяет «мокать» интерфейсы, виртуальные методы (и даже защищенные методы) и не позволяет «мокать» невиртуальные и статические методы.

ПРИМЕЧАНИЕ
На рынке существует лишь два фрейморка, позволяющих «мокать» все, что угодно. Это TypeMockIsolator и Microsoft Fakes, доступные в Visual Studio 2012 (ранее известные под названием Microsoft Moles). Эти фреймворки, в отличие от Moq, используют не кодогенерацию, а CLR Profiling API, что позволяет вклиниться практически в любой метод и создать моки/стабы даже для статических, невиртуальных или закрытых методов.

В этой статье хочу поделиться размышлениями об архитектуре серверных платформ для корпоративных приложений на Java с использованием Java EE, Spring, Akka.
Почему возникло желание написать? На JavaOne 2012 много было рассказано о трендах и изменениях в мире Java и JVM — Polyglot JVM, лямбды, модульность. На конференции возникло ощущение, что все наработки Java EE не должны зависеть от языка программирования. Сейчас часто задают вопрос – какой язык заменит Java? Но тогда куда девать все существующие технологии разработки корпоративных приложений? Эти технологии однозначно имеют ценность. Можно ли одновременно заменить язык программирования и при этом сохранить существующие наработки и сделанные инвестиции? Видимо да.
Теперь постараюсь подробнее – о влиянии тренда Polyglot JVM.
Введение Polyglot JVM достигает двух целей: открывает путь инновациям и позволяет сохранить все технологии Java в секторе корпоративных приложений. Но путь к этим выводам будет долгим;-)
Эта статья – для разработчиков корпоративных приложений. Надеюсь, она поможет систематизировать знания по архитектурам серверных платформ на базе Java и, возможно, вдохновит расширить диапазон используемых языков.

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

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

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

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

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

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

Единственной постоянной в разработке програмного обеспечения являются баги. Давайте посмотрим правде в глаза, нам никогда не удавалось сделать все правильно с первого раза. Из-за небрежности или неправильных предположений, разработка программного обеспечения становится похожа на приготовление пирога в мотеле, кишащим тараканами, за исключением того, что в нашем случае мы сами создаем жуков. К счастью Xcode дает нам множество инструментов для того, чтобы держать насекомых в ужасе. Очевидно что для этой цели существует отладчик, который мы знаем и любим, но есть еще многое что он умеет помимо просмотра переменных и построчной отладки. Это туториал для начинающих и продвинутых iOS разработчиков, где вы сможете получить практический опыт работы с некоторыми менее известными но черезвычайно полезными методами отладки, таких как:
— как избавится от NSLog в пользу логирования брейкпоинтов;
— как избавится от списка TODO в пользу генерации предупреждений компилятора;
— остановка на условиях с выражениями;
— динамическое изменение данных с помощью LLDB и многое другое.
Как вы можете заметить, целью для меня является быть ленивым разработчиком. К счастью LLDB позволяет сохранить мое время на мартини. Он предоставляет мне отличные инструменты для того, чтобы я не был приклеен к моему компьютеру в течении дня и ночи. Устраивайтесь поудобнее в кресле и открывайте свой любимый напиток. Время становиться ленивым!
Замечу что данный туториал подразумевает что вы уже знакомы с основами отладки в Xcode. Если вы новичек, рекомендую пройти сначала этот туториал.

Когда в конце 80 — начале 90 мы с друзьями заканчивали институт очень многие мечтали об иммиграции. Запад тогда притягивал своей загадочностью и новыми возможностями… Среди всех стран наибольшей популярностью пожалуй пользовалась Канада. Как страна с высокой степень толерантности населения, достаточно высоким уровнем жизни, большой территорией, богатыми природными ресурсами, неплохим развитием высоких технологий и многочисленной русскоязычной диаспорой. Ну и конечно близкий к нашему климат! Многие однокурсники с тех пор уехали и в Канаду и в США и в Австралию. Вернулся только один. Из Австралии, причём без дочки и жены.
Сейчас спираль истории совершила очередной виток и я снова очень серьёзно стал задумываться об иммиграции. Подобные мысли поселились и в головах большого количества талантливой молодёжи, которой не хочется делать карьеру в силовых структурах или идти в чиновники надеясь на неплохую прибавку к зарплате в виде откатов… Риски запуска и ведения собственного бизнеса становятся выше с каждым днём, а перспективы потерять собственное дело, а возможно и свободу в одночасье все реальнее.

Monodroid и Monotouch это фреймворки от xamarin, которые дают возможность разрабатывать приложение на языке C# для Android и iOS соответственно. Так как это относительно новая технология информации в интернете не слишком много (за исключением офф сайта и большого количества тем на stackoverflow.com), на русском языке же я не нашел никаких туториалов и информации вообще.

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

Недавно наша студия завершила разработку большого обновления — Captain Antarctica: Endless Run — для устройств на iOs. Кропотливая работа над обновлением затронула производительность, которая оказалась очень низкой на слабых устройствах. Я боролся с этим целую неделю и добился как минимум 30 FPS, а также значительного сокращения размера приложения. Хочу рассказать, как я это сделал, ну и как делать не стоит.
Статья пригодится любым разработчикам на Unity (причем не только менеджерам проектов и техническим специалистам, но и просто программистам, художникам и дизайнерам), потому что она затрагивает как оптимизацию на Unity в целом, так и конкретно оптимизацию 2d-приложений для мобильных устройств.

В этой статье мы решили немного рассказать о средствах continuous integration (CI), которые используем в компании Дневник.ру, и поделиться небольшими наработками в этом направлении. Большая часть материала может показаться банальной рекламой выбранного движка CI или попыткой вызвать holy war (причем не один), но подобного не было в целях. Статья также не является путеводителем или описанием каких-либо фитч и может быть расценена как статья от кэпа – главное, чтобы она была интересна и вызвала дискуссию.

Сегодня я хочу рассказать о том, почему и как мы пришли к использованию препроцессора Stylus в разработке Яндекс.Почты, а также описать используемый нами метод работы со стилями для IE. Он очень легко реализуется именно с помощью препроцессоров и делает поддержку IE простой и удобной. Мы разработали для этого специальную библиотеку, которой тоже поделимся — if-ie.styl.

Это только первая статья из серии статей об использовании препроцессора Stylus в Яндекс.Почте, которые мы готовим к публикации.

Все мы знаем как хорошо и похвально принимать участие в разработке открытых проектов.
К тому же потом можно мерятся количеством коммитов в rails и зарплату попросить побольше.

А что если вы решили написать свой open source проект?

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

Приветствую! Надеюсь, эта статья будет кому-нибудь полезна.

Многие знают о возможностях адресной строки Chrome, запоминающей поисковые системы различных сайтов. Однако эффективно ее использовать, думаю, умеют далеко не все.
Я сижу в интернете исключительно через этот браузер (дело вкуса и привычки, конечно) и использую кастомизированный поиск в Chrome по несколько десятков раз в день. Большое количество действий, ежедневно выполняемых через браузер, можно оптимизировать, добавив в список определенные поисковые системы.

Итак, кончаю муть, перехожу к «технической» и практической стороне дела.

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

Я отвечу на вопросы: Что тестируем? Кто этим занимается? Зачем это все происходит? Что у нас есть?
А затем расскажу как все работает: опишу круги тестирования — с первого по девятый.

Что?

Наш продукт — корпоративное web-приложение Service Desk, написано на java.

Кто?

Я — лид группы автоматизированного тестирования; программисты код которых тестируем; ручные тестировщики, рутину которых мы искореняем; менеджеры верящие, что если тесты прошли, то все не так уж и плохо.

Зачем?

Цель моей группы — уберечь продукт от регрессионной спирали смерти.
Задача группы — необнаружение дефектов максимумом интересных способов с минимальным количеством ручного труда.

Что у нас уже есть?

900 коротких и не очень сценариев использования приложения закодированых в тесты.
CI Jenkins на шести серверах, три СУБД, два семейства ОС и три браузера под которые пишем продукт.

Как это работает?

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

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



И я стал учиться работать управленцем.

Проглядывая книжку «Эффективное использование C++», Скотта Мейерса, которая ( и я никого не удивлю ) достойна всяческих похвал, меня очень тронуло, то с какой возбуждённостью, вдохновлённостью, трепетом ( может мне показалось? ) автор говорит о шаблонах и их возможностях. Приведу маленький кусочек:

Метапрограммирование шаблонов ( template metaprogramming — TMP ) — это процесс написания основанных на шаблонах программ на C++, исполняемых во время компиляции. На минуту задумайтесь об этом: шаблонная метапрограмма — это программа, написанная на C++, которая исполняется внутри компилятора C++…
Было доказано, что технология TMP предоставляет собой полную машину Тьюринга, то есть обладает достаточной мощь для любых вычислений...

Да уж… сердце забилось, в очередной раз удивился — только подумать — полная машина Тьюринга со всеми вытекающими последствиями… Как по мне, это просто невероятно и удивительно… хотя, кто его знает…

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

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