Прочитав предыдущий пост, а именно его часть про «Образование на Западе», не мог удержать себя, чтобы не написать данный пост.

Так получилось, что после окончания (по настоянию родителей) медицинского университета в России судьба занесла меня в Германию, где я принял решение в 28 лет пойти снова учиться, выбрав в качестве профессии информатику (которая до этого была моим основных хобби). Сейчас я заканчиваю второй курс (как раз экзамены до конца сентября), перехожу от «вводного курса» (Grundstudium) в «основной курс» (Hauptstudium).

Итак, как проходит обучение информатике в Германии.

Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

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



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

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

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

• Трекинг источников установок (такие инструменты как Mobile App Tracking, AppsFlyer и ADXtracking, используются, как правило, для продвижения приложений);
• Аналитика внутри приложения (наиболее известные инструменты – это Flurry, Google Analytics, Яндекс.Метрика и Mixpanel, которые предоставляют возможность наблюдать за поведением пользователей внутри мобильного приложения, что позволяет принять решение о дальнейшем развитии вашего продукта);
• Сбор статистики из магазинов приложений (самые популярные сервисы – это App Annie и Distimo, позволяют отслеживать позицию в сторе как вашего приложения, так и конкурентов).

Поскольку данная статья предназначена для разработчиков, речь в ней пойдет о том, как внедрить аналитику в приложение Windows Phone. В качестве системы аналитики будет рассмотрена Flurry Analytics.

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

На примере простого Windows 8.1 приложения посмотрим насколько просто переносить приложения с WinRT (Windows 8.1) на Silverlight (WP8.0) и по ходу разберем несколько подводных камней.

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

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

Сразу оговорюсь — вполне возможно, что средствами Adobe Illustrator можно сделать всё то, о чём написано в статье и уже есть готовые скрипты. Но его нет под линуксом и вообще он дорого стоит. Думаю, что пользователи Linux и сторонники свободного ПО оценят мой подход.

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

Я уже много лет являюсь поклонником серии «Effective XXX», начатой Скотом Мейерсом в 1997-м году с его “Effective C++”. Книги из этой серии содержат несколько десятков советов о вашем любимом языке программирования, рассказыавя о том, что делать стоит, а чего – нет. Такие книги легко читать, и они являются отличным источником для размышлений.

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

Интернет сделал нас ленивыми!

Почему? Кто в последний раз посмотрел видео больше 3х минут? Кто прочитал пост больше 2 страниц? Какой заголовок более привлекателен, «63 способа бла-бла-бла» или «3 проверенных метода бла-бла-бла»? А если эти три проверенных метода выделены от основного текста, то это вообще гуд (можно не читать текст вовсе, а просто пробежаться по выделенным подзаголовкам).

В этом свои плюсы. Наш мозг эволюционировал, и обрабатывает информацию быстрее, чем, скажем, 15-20 лет назад (да и эволюционирует быстрее, чем это было возможно век назад). Как компании справляются с высокими нагрузками? Как процессор выполняет программу по возможности быстро? С помощью кэширования! (как вариант, но самый приоритетный). Что делает наш мозг, чтобы справиться с большой нагрузкой? Кэширует! Что именно и как — оставим на размышление ИИшникам (специалистам по искусственному интеллекту). В противном случае при увеличении размера обрабатываемой информации время «отклика» бы увеличилось в разы, и на ответ на «как добраться до ближайшей больницы?» уйдет больше времени, чем человек «в силе ждать». «Сила ждать» тоже уменьшилась, «размер» нашего терпения уменьшился, и мы быстро устаем, если продолжительность видео большая, размер статьи большой (на самом деле продолжительность может не влиять на терпение, больше всего влияет полезная информация, если «воды» меньше или вовсе нет, то и терпеть ничего не приходится, посему данный пост написан «эз лаконик эз посибл»).

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

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

Для самых нетерпеливых по ссылкам ниже находится готовый прототип.
Онлайн версия
Скомпилированная версия для Windows [Зеркало] ~7.5 МБ

Что мы собираемся делать? Двумерную головоломку с колобком в роли главного героя, который может двигать ящики, которые могут нажимать кнопки, которые могут открывать двери, за которыми скрывается выход из уровня, который построил я. Или вы, у нас же здесь туториал как-никак.

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