Введение

Я уже писал о том, как сделать SOAP Message Based веб-сервис на WCF. А сейчас хочу рассказать о проектировании и построении RESTful Message Based веб-сервисов на WCF. Для понимания данной статьи необходимы базовые знания о REST и о том, как создавать RESTful веб-сервисы на WCF. Для ознакомления с RESTful веб-сервисами вы можете ознакомиться с: A Guide to Designing and Building RESTful Web Services with WCF 3.5.

В статье я постараюсь раскрыть и решить проблемы дизайна RESTful. Вы узнаете, как построить RESTful веб-сервис, который:

• Обладает стабильным и универсальным интерфейсом.
• Передает данные в соответствие с паттерном DTO.

По следам недавнего топика «Обработка больших объемов данных в памяти на C#» представляю перевод упоминавшейся там статьи о структурах.

Структуры являются фундаментальными типами данных в C# и большинстве других современных языках программирования. По своей сути структуры просты, но вы можете удивиться, насколько быстро работа с ними может стать сложной. Чаще всего проблемы возникают, если вы должны работать со структурами, созданными в других языках и сохраненными на диске или полученными в результате вызова функций из библиотек или COM-объектов. В этой статье я подразумеваю, что вы знакомы с понятием структуры, умеете определять их и владеете базовыми навыками работы со структурами. Предполагается, что вы имеете представление о том, как вызывать API функции с использованием p/Invoke, а также что такое маршалинг. В случае неуверенности в своих знаниях вы можете обратиться к документации.
Множество техник, описанных в данной статье, могут быть расширены и применены к любым типам данных.

Сейчас в тематических интернетах модно слово «Node.js». В этой небольшой статье мы попробуем понять («на пальцах»), откуда всё это взялось, и чем такая архитектура отличается от привычной нам архитектуры с «синхронным» и «блокирующим» вводом/выводом в коде приложения (обычный сайт на PHP + MySQL), запущенного на сервере приложений, работающем по схеме «по потоку (или процессу) на запрос» (классический Apache Web Server).

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

Python-inject — это небольшая библиотека для внедрения зависимостей в Питоне. Третья версия написана в unix-стиле, т.е. она прекрасно выполняет только одну функцию и не пытается быть всем. В отличие от уже упомянутых Спринга и Джуса Инжект не ворует конструкторы классов у разработчиков, не навязывает разработчикам необходимость писать приложение в каком-то определенном стиле и не пытается управлять всем графом объектов приложения.

Инжект практически не требует конфигурации (об этом подробнее подкатом) и очень прост в использовании.

Часть 1: заготовка персонажа и анимация покоя
Часть 2: бегущий персонаж
Часть 3: прыжки (и падения)

Всем привет. Продолжаем дело, начатое в первой части. Сейчас у нас есть платформа и стоящий на ней персонаж с анимацией покоя. Настало время научить нашего персонажа бегать вправо-влево по платформе.

Всем привет! Решил поделиться своим велосипедиком для работы с WWW в Unity3D.

Что такое WWW?

WWW — это класс, который позволяет отправлять веб запросы на указанный URL и получать ответ в виде текста, текстуры, загружать бандлы. Подробнее можно прочесть в справке (клац).

Я остановлюсь на текстовом формате данных.

Предпосылки

Иногда возникает задача связать игру с сервером, написанном на Php(хотя можно любой другой яп использовать для развертки backend части). Все время отправлять запросы в виде new WWW(Address + "?api=login&username=..."); не удобно, хочется сделать удобнее работу с посылкой/приемом данных.

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

В итоге, созрела мысль написать нечто, что могло бы упростить жизнь для работы с WWW.text.

Часть 1: заготовка персонажа и анимация покоя
Часть 2: бегущий персонаж
Часть 3: прыжки (и падения)

Всем добрый день. В относительно недавно вышедшей Unity 4.3 появились инструменты для создания 2D игр. Конечно, такие игры можно было создавать и раньше, но это делалось при помощи дополнительных ухищрений (вот пример с хабра). Теперь же появилась поддержка 2D «из коробки». Надеюсь, разработчики продолжат ее развивать, а пока я хочу рассказать о некоторых приемах работы с новыми 2D инструментами.

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

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

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

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

DISCLAIMER: Эта заметка подразумевает наличие у читателя базовых знаний о юнит тестах, в чем автор этих строк не сомневается, а также базовых знаний о проектирование по контракту, которые можно пополнить начиная отсюда.

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

Итак, давайте вкратце рассмотрим, в каком именно месте находится пересечение контрактов и юнит тестов, и постараемся ответить на вопрос: являются ли постусловия избыточными при наличии юнит тестов?

Я думаю, что многие разработчики знают, что цикл foreach в языке C# не так прост, каким он кажется на первый взгляд. Для начала давайте ответим на вопрос: «А что нужно, чтобы конструкция foreach успешно компилировалась?». Интуитивным ответом на этот вопрос кажется что-то типа: «Реализация классом интерфейса IEnumerable или IEnumerable<T>.». Однако, это не так, ну, или не совсем так.

Полный ответ на этот вопрос такой: «Для того чтобы конструкция foreach успешно компилировалась необходимо, чтобы у объекта был метод GetEnumerator(), который вернет объект с методом MoveNext() и свойством Current, а если такого метода нет, то тогда будем искать интерфейсы IEnumerable и IEnumerable<T>».

Причин у такого «утиного» поведения две.

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

Автоматический подсчет ссылок (Automatic Reference Counting, ARC) для языка Objective-C был представлен компанией Apple еще в 2011 году для iOS 4.0 и выше, Mac OS X 10.6 и выше, с использованием xCode 4.2 и выше. И, хотя всё больше библиотек, фреймворков и проектов сегодня используют ARC, до сих пор среди программистов встречается либо неприятие этой технологии, либо eё неполное понимание. Опытные программисты, привыкшие к retain/release, иногда считают, что они лучше и эффективней справяться с подсчетом ссылок, чем это за них сделает компилятор, а новички, начищающие сразу использовать ARC, полагают, что им не надо вообще думать об управлении памятью, и всё сделается магическим образом само.

От переводчика: Это перевод первой статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.

---

Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.


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

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

Я иногда путешествую по разным странам, и языковой барьер, довольно часто, становится серьезным препятствием для меня. И если в странах, где используются языки германской группы, я еще как то могу сориентироваться, то в таких странах как Китай, Израиль и арабские страны без сопровождающего, путешествие превращается в загадочный квест. Невозможно понять местное расписание автобусов/поездов/электричек, названия улиц в небольших городах очень редко есть на английском языке. А уж проблема с выбором, что бы поесть, из меню на непонятном языке вообще сродни ходьбы по минному полю.
Так как я разработчик под iOS, я подумал, а почему бы не написать такое приложение: наводишь камеру на вывеску/расписание/меню и тут же получаешь перевод на русский.

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

До чего бывает неприятно: есть 32-битная библиотека на C++, которую вы уже много лет лицензируете клиентам, а теперь все больше и больше клиентов хочет использовать ее из 64-битных программ. Вы развиваете библиотеку, исправляете ошибки, дорабатываете, холите и лелеете ее, она прекрасно работает, а клиентам это не так и важно – они просто хотят 64 бита. Им даже не важно, будет ли она вся 64-битной, они просто хотят ее использовать.
 
Что делать? Очевидно – переписать код так, чтобы он компилировался и на 32 бита, и на 64:
— читаем много статей – например, вот эту и те, что появятся в «похожих публикациях» при ее прочтении;
— быстренько правим код (за неделю должны управиться, правда?);
— ???
— PROFIT
 
А теперь добро пожаловать в реальный мир.

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

Недавно прочтенная статья заставила меня кардинально изменить взгляды.

Сегодня мы поговорим о распределенных, гетерогенных и местами довольно серьезно и разнообразно нагруженных интернет приложениях на примере портала http://www.abbyyonline.com. Я постараюсь не углубляться в технические подробности, имеющие отношение к конкретной платформе, и, хотя основная часть описанного приложения реализована на ASP.Net MVC, возможно, данный материал заинтересует всех, имеющих отношение к веб-разработке, вне зависимости от используемого инструментария.

В нашем блоге мы уже немного рассказывали о старых версиях ABBYY Lingvo, но всё время за рамками постов оставалось главное в истории словаря – как же он создавался. Было это больше двадцати лет назад – срок немалый, но в ABBYY люди работаю долго, и Александр Москалёв, который спроектировал первую версию Lingvo в 1989 году, до сих пор в компании. Мы попросили рассказать его о том, как всё начиналось, – и вот что из этого получилось.