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

И не надо…

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)
«Галоп пикселя», часть VI — Анимация персонажей. Бег (линк)

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

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

Материал разделен на несколько публикаций в виду объема текста и изображений. Каждая статья имеет свою степень сложности, однако, все из них наглядны и могут быть использованы как руководство к действию.

Боевые системы наших игр Rimelands: Hammer of Thor и Trulon: The Shadow Engine были высоко оценены игроками. Несмотря на то, что это два сильно отличающихся взгляда на систему боя в RPG, они имеют много общего в дизайне механик и иллюстрируют мою личную философию дизайна. В обоих играх используются пошаговые бои, но Trulon они основаны на колоде карт, а в Rimelands — на наборе кубиков. В первой вы управляете целой партией персонажей, во второй — только одним героем. У этих игр есть сходства и различия не только в боях, но в данной статье я расскажу только о базовых боевых механиках.

Основано на реальных событиях, происходящих повсеместно и в рамках полемики вот здесь

Эта история началась довольно банально. Сотрудники во время работы на некую компанию создали программу, которая успешно продавалась. Затем основали собственную фирму и стали заниматься тем, что умеют лучше всего – продолжили продавать тот же самый софт. Бывший работодатель возмутился такому подходу к конкуренции и попытался запретить использование «своего» продукта в «чужих» интересах. Авторы придерживались ровно противоположного мнения. Заметив, что вопрос мирно не решается, работодатель подает в суд. Вот вам и довольно типичное дело из судебной практики.

Кто прав? Суд привлечет авторов к ответственности или встанет на их сторону?

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

Часть вторая

Всем заинтересовавшимся — добро пожаловать под кат!

Я начинающий программист на Java, и путь мой пройден тысячами.



Сначала идет долгий и мучительный выбор Самой Правильной Книги, затем первый восторг от работы перепечатанных из нее листингов программ. Затем осознание растущей крутости и профессионализма. Падение в яму собственного ничтожества, при попытке написать что-то самостоятельно. И долгий путь наверх.

В моем случае Самой Правильной Книгой стал двухтомник «Java. Библиотека профессионала.» за авторством Кея Хорстманна и Гари Корнелла, а самой первой книгой, которая открыла дверь в мир Java – Яков Файн «Программирование на Java для детей, родителей, дедушек и бабушек».

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

В статье рассмотрим как написать на ES6 составляющие части AngularJs приложения, затем собрать с помощью Browserify и Babel на основе небольшого приложения, которое вы можете скачать с github и поиграться.

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

Задача

В тестовом заданий от компании Wheely мне предстояло реализовать аутентификацю через код в смс-сообщении. Суть процесса в следующем:

1. Пользователь совершаете какое-либо действие.
2. Для подтверждения этого действия генерируется код.
3. Код отправляется в СМС-сообщении.
4. Пользователь указывает ключ.
5. Ключ проверяется на соответствие.

Результатом должно было стать самостоятельное приложение, которое выполняет задачи, обозначенные в пунктах 2, 3 (только имитация), 5. Пины становятся не актуальны через 2 минуты после генерации. Все остальное на мое усмотрение.

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

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

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

Как-то давно переводил статью «Понимание типов сервисов в AngularJS (constant, value, factory, service, provider)». На практике, конечно, не всё пригождается, поэтому в рамках понижения порога вхождения в Ангуляр, объясню проще.

 Цель статьи: дать пару идей для автоматизации, а может даже и рабочий инструмент для создание T4-болванок под решения типовых задач, производимых с классами/интерфейсами в работе.

Введение

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

• WinForms
• WPF
• Silverlight 5
• Silverlight for WP7.1, WP8, WP8.1
• Xamarin.Android
• Xamarin.iOS
• Xamarin.Forms
• WinRT XAML framework for Windows 8 Store apps

Мы с вами люди рабочие и зачастую не замечаем ничего что происходит за пределами нашей работы. Так и я, работая изо дня в день, знаю только про свой SpecFlow и смежные вопросы. Но ничего – по сторонам. Этим постом я хочу восполнить пробелы новостей в области .Net

Новости хаба .Net на Хабре занимают 33 страницы или 328 постов. Что говорит о том что новости появляются почти каждый день =) Посмотрим на самое интересное из них (на мой скромный взгляд). Ну и загляните под кат: до ката, конечно же, не все.

Доступен новый JIT: теперь с поддержкой SIMD
Как работает декомпиляция в .Net или Java на примере .Net
Microsoft раскрыла исходный код компилятора С#
Consulo: ~1000 коммитов, или как прошла осень
Под капотом у Stopwatch
Как тестировать код финализатора (c#). Послесловие: тест все-таки упал

В последние годы REST (REpresentational State Transfer) стала стандартной архитектурой при дизайне веб-сервисов и веб-API.

В этой статье я покажу вам как просто создавать RESTful веб-сервисы используя Python и микрофреймворк Flask.

Что такое REST?

Характеристика системы REST определяется шестью правилами дизайна:

• Клиент-Сервер: Должно быть разделение между сервером, который предлагает сервис и клиентом, который использует ее.
• Stateless: Каждый запрос от клиента должен содержать всю информацию, необходимую серверу для выполнения запроса. Другими словами, сервер не обязан сохранять информацию о состоянии клиента.
• Кэширование: В каждом запросе клиента должно явно содержаться указание о возможности кэширования ответа и получения ответа из существующего кэша.
• Уровневая система: Клиент может взаимодействовать не напрямую с сервером, а с произвольным количеством промежуточных узлов. При этом клиент может не знать о существовании промежуточных узлов, за исключением случаев передачи конфиденциальной информации.
• Унификация: Унифицированный программный интерфейс сервера.
• Код по запросу: Сервера могут поставлять исполняемый код или скрипты для выполнения их на стороне клиентов.

    

Некоторое время назад на просторах сети столкнулся с интересной библиотекой Breeze.js. Первая мысль, которая пришла на ум при взгляде на неё: «Да это же как Entity Framework для браузера». В поисках информации и отзывов других пользователей, конечно, первым делом поискал статью на Хабре, но не нашёл, поэтому и решил написать, в надежде, что кому-нибудь это тоже будет полезным. Статья написана в виде tutorial по созданию проекта на основе Breeze.js, Angular.js, ASP.NET Web API и Entity Framework.

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

Технический директор REG.RU Валерий Студенников попытался решить транспортную проблему лично для себя, а затем превратил своё хобби в интересный стартап.

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

ConcurrentQueue можно отнести к lock-free конкурентным структурам данных. В ее реализации нет блокировок (lock, Mutex…) и реализована она с использованием:
— классической функции CompareExchange;
— SpinWait
— volatile (используется как memory-barrier)
В основу ConcurrentQueue заложена структура ring-buffer (кольцевой буфер).

Невозможно, просто взять и вникнуть в этот глубокий смысл, изучая События (event) в просторах базового и, на первый взгляд, бесконечного C#.

Когда я изучал События (не в рамках .NET!), потратил много сил, чтобы, наконец-то, разобраться, как они устроены и должны конструироваться. Поэтому, я решил опубликовать свою методику понимания структуры пользовательского события, коим представляется ключевое слово event в С#.
Не буду цитировать и без того замученную MSDN, а постараюсь объяснить понятно и доступно.

Все началось с одного собеседования, которое и натолкнуло меня к написанию данной статьи. Довольно большая часть разработчиков на платформе .Net не понимает базовые вещи, хотя и использует их повседневно, например lock-ом оборачивают все методы, использующие ConcurrentDictionary, хотя можно было бы обойтись обычным Dictionary<>.

В науке существуют 3 основных способа реализации конкурентных структур данных:
• Lock-free структуры данных;
• Fine-grained блокировка;
• Transactional memory implementation(транзакционная память);

ConcurrentDictionary<TKey, TValue> — это thread-safe аналог Dictionary<TKey, TValue>. В его основе лежит, так называемый Fine-grained блокировка.