Картинка из гугла для привлечения внимания.

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

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

Для тех, кому лень читать: наш выбор — качалочка и плавание. Бег, игры и велик — по желанию.

Хочу рассказать о своем участии и победе в ежегодном соревновании по программированию ИИ «Russian AI Cup 2015» от Mail.Ru Group. Посмотреть подробные правила соревнования и записи игры желающие могут на сайте соревнования russianaicup.ru.



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

Участнику предлагалось написать ИИ для управления автомобилем в гонках на выживание. Как и в прошлом году, задача была «с физикой». Но на это раз исходники «физического движка» были открыты. Еще, в отличие от прошлого года, на этот раз все случайные явления в игровом мире были наглядны — случайная карта, случайно расставленные бонусы. Сразу было видно — когда удача на твоей стороне, а когда она от тебя отвернулась. В прошлогоднем хоккее, даже наблюдая за игрой значительно отличающихся по силе противников, было трудно понять произошел выигрыш благодаря случаю или мастерству. Думаю, это положительно сказалось на зрелищности соревнования.

Краткое описание правил

Цель — проехать 2 круга по замкнутой трассе быстрее всех. Точнее надо набрать больше всех очков, но приехать первым — это основной способ заработать очки. Еще очки дают за сбор бонусов по дороге и нанесение урона противникам. Трасса, как конструктор, собирается из квадратных «тайлов», это прямолинейные участки трассы, углы (поворот трассы на 90 градусов), или перекрестки (Т образные и обычные). Нужно ехать по ключевым точкам («тайлам») трассы в определенном порядке – иногда приходится делать петли, иногда вообще ехать назад. Еще у машинок есть возможность разливать за собой лужи мазута, стрелять друг в друга специальными снарядами (шины и шайбы), и использовать особый ускоритель «нитро». Заряды для всех этих приспособлений ограничены, и пополняются подбиранием случайно разбросанных по карте бонусов.

Расскажу, как устроен мой ИИ, и благодаря чему (как я думаю) удалось победить.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

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

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

О чем данный учебник

Данный учебник представляет собой что-то типа «штампа моей памяти» по языку SQL (DDL, DML), т.е. это информация, которая накопилась по ходу профессиональной деятельности и постоянно хранится в моей голове. Это для меня достаточный минимум, который применяется при работе с базами данных наиболее часто. Если встает необходимость применять более полные конструкции SQL, то я обычно обращаюсь за помощью в библиотеку MSDN расположенную в интернет. На мой взгляд, удержать все в голове очень сложно, да и нет особой необходимости в этом. Но знать основные конструкции очень полезно, т.к. они применимы практически в таком же виде во многих реляционных базах данных, таких как Oracle, MySQL, Firebird. Отличия в основном состоят в типах данных, которые могут отличаться в деталях. Основных конструкций языка SQL не так много, и при постоянной практике они быстро запоминаются. Например, для создания объектов (таблиц, ограничений, индексов и т.п.) достаточно иметь под рукой текстовый редактор среды (IDE) для работы с базой данных, и нет надобности изучать визуальный инструментарий заточенный для работы с конкретным типом баз данных (MS SQL, Oracle, MySQL, Firebird, …). Это удобно и тем, что весь текст находится перед глазами, и не нужно бегать по многочисленным вкладкам для того чтобы создать, например, индекс или ограничение. При постоянной работе с базой данных, создать, изменить, а особенно пересоздать объект при помощи скриптов получается в разы быстрее, чем если это делать в визуальном режиме. Так же в скриптовом режиме (соответственно, при должной аккуратности), проще задавать и контролировать правила наименования объектов (мое субъективное мнение). К тому же скрипты удобно использовать в случае, когда изменения, делаемые в одной базе данных (например, тестовой), необходимо перенести в таком же виде в другую базу (продуктивную).

В своей статье я хотел бы рассказать о теории относительности. Эта теория не требуется в представлении. С самого своего создания она была окутана ореолом тайны, поскольку полностью подрывает наши привычные представления о пространстве и времени. Все мы в школе учили формулы теории относительности, но мало кто действительно понимал их. И это не удивительно, ведь человеку, чтобы по-настоящему понять какую-то теорию во всей её красоте, полноте и непротиворечивости, не достаточно знать формулы. Нужно иметь какой-то визуальный ориентир, нужна динамика, чтобы было что-то, что можно повертеть в руках. Я решил восполнить этот пробел и написал небольшую программку, в которой можно «повертеть в руках» пространство-время. Мы, как настоящие исследователи, с помощью небольших экспериментов попытаемся выяснить основные свойства этой загадочной материи.
Под катом много картинок (и ни одной формулы).

Flurry уже стала мастхевом для тех мобильных разработчиков, которые понимают важность анализа пользовательского поведения. Однако в тех метриках Flurry, которые касаются удержания пользователей, сориентироваться не так-то легко: тут и return rate, и rolling retention, и static retention… в общем, как говорит народная мудрость, без ста грамм не разобраться. Поправим — не разобраться без этой статьи, которую мы в Alconost отыскали и перевели специально для Хабра. А понимать, что к чему в показателях удержания пользователей, жизненно важно: иначе вы рискуете потерять и пользователей, и деньги на их привлечение, и радужные перспективы развития вашего приложения или игры.

Всем привет! Меня зовут Александр Гришин, я работаю в студии IT-Territory (Mail.Ru Group) специалистом по тестированию. Я занимаюсь разработкой Android-версии «Эволюции: Битва за Утопию». iOS-аудитория с интересом встретила новинку весной этого года, и мы уже готовимся к первым впечатлениям Android-юзеров. В статье я расскажу о том, как мы портировали игру на Android и с какими трудностями и нюансами столкнулись в процессе.

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

Смотрите, я — самый настоящий инди разработчик компьютерных игр! А все потому, что я делаю компьютерные игры.

Вот уже больше года я тружусь над игрой Fancy Skulls, шутером от первого лица со случайной генерацией уровней и перманентной смертью, проще можно сказать что это стрелялка-рогалик.


Я расскажу о том, что я уже сделал, чему научился, и что собираюсь делать дальше. Может быть, стоило бы подождать когда игра будет закончена и написать постмортем, но я ведь тогда что-то забуду а что-то поленюсь записать, а так получится как бы сериал. Чем все закончится? Попадет ли моя игра в Стим через Greenlight и буду ли я благодаря этому во фраке и с моноклем в левом глазу прогуливатся по Невскому Проспекту в лакированых туфлях с белыми гамашами? Если да, то как и когда? Что такое гамаши? Оставайтесь с нами и вы все узнаете.

Последние несколько лет я руковожу небольшой геймдев студией, и на протяжении всего это времени ко мне периодически обращаются люди не из индустрии, которые «хотят дать денег» и получить себе проект. При этом представление этих людей о том, что такое игровая индустрия, скажем так, далеко от реального. Это статья — моя попытка рассказать о том, что сделать игру стоит больше, чем 200$, сделать поярче и заработать миллион — это не бизнес-план, и вообще, геймдев — это высокорискованный бизнес, а не принтер для денег.

Я технический евангелист компании Unity Technologies, и моя работа — путешествовать. За пару часов до Нового Года я насчитал в своем календаре 23 командировки по разным конференциям и мероприятиям в 2013-ом. В 2012-ом ситуация была похожа, но фокус был больше на Западную Европу. А теперь пришло время делиться опытом.

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

Итак, постараемся восполнить пробел и открыть тему торговых марок. Очевидно, что с точки зрения программирования легко повторить и tetris, и facebook, и любые «фермы». Но попробуйте раскрутить свой продукт (клон он или нет) с похожими на эти продукты названиями — тут же владельцы (вернее их юристы) вас закроют со всех ресурсов. С другой стороны, если ваш продукт становится популярным, то тут же назревает необходимость защитить его от клонов и сделать так, чтобы другие не использовали и не забивали вашу марку в свои ключевые слова. Если коротко — это и есть причина, по которой торговая марка выступает одним из основных параметров оценки и стоимости любого IT проекта при его финансировании, продаже и заключении солидных контрактов.

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

В этой лекции Елена Грунтова раскрывает студентам Малого ШАДа понятие грамматической категории и подробно рассказывает падежах, их природе, типах, а также способах выражения.

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

«Качество появляется только тогда, когда кто-нибудь несёт ответственность лично».
— Фредерик Ф. Брукс



Привет, хабр!

Предлагаю вашему вниманию вольный перевод эссе "A Generation Lost in the Bazaar" Пола-Хеннинга Кампа, повествующего нам о печальной судьбе поколения IT-профессионалов, выросших в период бума доткомов, а также о фундаментальных проблемах в UNIX, напрямую влияющих на качество и портабельность ПО. Обо всём по порядку.

Название оригинала: Building Windows 8 Apps with C# and XAML
Автор: Дж. Ликнесс
Перевод книги: Заика А. А.
Дата выхода: июль 2013г.

Книга на сайте издательства.
Книга на Ozon.ru

Электронная версия в продаже!

Подробное оглавление
Отрывок

Подлинная история.

Жесткий диск, который хранил раздел /home на моей Linux машине, накрылся и я должен был заменить его новым. Так как системный блок находится под столом, то я должен был отключить все кабели, достать его, поменять жесткие диски местами и вставить все это обратно.

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