Я думаю, что многие из вас сталкивались с задачей валидации данных в формах. Это долго, утомительно и часто требует значительных усилий. Порой мне кажется, что ребята из Редмонта издеваются над нами, предлагая проводить валидацию так. Шучу, конечно, но этот метод мы использовать не будем.

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

В понедельник утром за неделю до Нового Года этот вопрос, думаю, актуален для многих.

Есть куча статей на эту тему. Вот основные советы:

• Начинайте с самой сложной задачи
• Сделайте первый шаг — продолжать будет уже легче
• Составьте план и неукоснительно ему следуйте
• Занимайтесь любимым делом
• Не отвлекайтесь

Всё просто. Закройте Хабр и приступайте к работе!

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

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

Всем привет!
У нас хорошая новость! Уже в продаже книга «Универсальные методы дизайна». Эта книга является продолжением серии «Универсальные принципы дизайна». В этой книге в числе прочего на каждом развороте в левой части предлагается краткое текстовое описание метода, сопровождаемое ссылками на работы авторов.



Прототип: Universal Methods of Design: 100 Ways to Research Complex Problems, Develop Innovative Ideas, and Design Effective Solutions
Publisher: Publisher: ROCKPORT
Publication Date: 17-Jan-2012

Книга доступна в печатном виде. До 9 ноября 2013 года для посетителей Хабры действует купон на скидку 20%. Чтобы получить скидку, при оформлении заказа введите код купона: 238650081c8186c9636cb

Аннотация:

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

На краудфайндинговой платформе Kickstarter идет сбор средств на реализацию проекта костюма виртуальной реальности PrioVR. Он представляет собой комплект беспроводных датчиков движения и хаб-контроллер. Костюмчик отслеживает движения рук и ног (три точки на конечность), что делает ненужными всякие PS Move, Wii Remote и т. п.

Техническое собеседование – практически неотъемлемый атрибут трудоустройства любого разработчика, а для старших разработчиков – проведение их (собеседований) ещё и чуть ли не повседневная обязанность. Но как за короткий срок (в идеале 20-30 минут) составить у себя более менее приемлемое представление о реальном опыте соискателя?

Некоторое время назад уже был опубликован аналогичный пост, с тех пор количество дополнений для Visual Studio 2010,2012 и 2013 перешагнуло планку в 4к, появилось немало новых дополнений. Ниже перечислено 20 наиболее популярных или интересных расширений для Visual Studio 2012 и 2013 в дополнение к предыдущему посту.

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

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

Немножко пятничного настроения в субботу. Я думаю, все видели этот код:



Но Aras Pranckevičius пошел еще дальше. Как написать код, который не так просто обнаружить?
И если вначале идут простые примеры, то дальше начинается…

(Вы не любите Seagate? Вы просто не умеете их готовить!)
Для NAS пришлось купить HDD 3TB WD Caviar Green IntelliPower (других трёшек просто не было). Руки привычно взяли «напильник» и начали «снимать фаску», из глаз слёзы обиды — семь с половиной тысячи за ЭТО. Да «гарантия», да RAID5, но держать в уме предстоящий через 6-8 месяцев ребилд 6 террабайтного массива?! И тут новость о снижении вендорами сроков гарантии. Нет, я отлично понимаю, почему уменьшают гарантию,- ЭТО работать вообще не должно. Но почему не повышают качество изделий? Впрочем, и это понимаю,- надо чтобы продавалось много, а не работало долго. А то вот мои три 2ТБ Барракуды уже второй год под торрентом 7/24 работают и не бэдят, а Seagate голодает.
И так, если вас греет гарталон — этот топик вам будет не интересен. Если у вас RAID6 из Seagate 7200 Constellation ES — ваше время слишком дорого стоит, что бы читать такие мелочи. Если вы потратили свои кровные и хотите «что бы не было мучительно больно» — загляните под кат, может найдёте что-то полезное.

Работаю в IT уже более 12 лет. Думал, что без проблем справляюсь с менеджментом задач, которые отдаем во фриланс. Но последний случай буквально выбил меня из колеи: получил весьма дорогой и негативный опыт. До сих пор обдумываем с коллегами что было сделано верно, а что нет. Предлагаю вашему вниманию 10 выводов-советов, которые мы сделали для себя. Надеюсь, они будут полезны и вам. Если у вас есть что еще посоветовать, то welcome в комментарии.

1. Всегда фиксируйте «правила игры» в договоре

Отнеситесь к этому пункту со всей внимательностью! «Правила игры»/Договор — это не просто формальность. Не надо скачивать типичные договоры из интернета.
Договор должен быть выстрадан: это квинтэссенция того как именно вы хотите работать, по каким бизнес процессам и по каким правилам. Он должен включать в себя все ваши формальные договоренности с исполнителем: начиная от того где именно будет вестись список задач/замечаний и заканчивая наградами/штрафами за невыполнение в должный срок и должного качества задачи.
Не забудьте показать данный договор самому исполнителю: он обязательно что-то захочет добавить и поправить. Важно это сделать на первых этапах работы с исполнителем: если что-то в договоре вызывает большие споры, то от такого исполнителя лучше отказаться. Если он спорит сейчас, то что будет в реальной ситуации? Меняя договор под пожелания исполнителя, помните: проект ваш, платите за него тоже вы, а значит удобно работать должно быть, в первую очередь, именно вам!

Не секрет, что создание дизайна приложения под Windows Phone или Windows 8 занимает гораздо меньше времени, чем под iOS или Android. И дело тут не только в специфике дизайна. Главным фактором экономии времени является налаженный алгоритм взаимодействия дизайнера с разработчиком. Инструмент, который соединяет дизайн и код — Blend, входящий в пакете Visual Studio.



Как это работает?
Как правило дизайнеры создают макеты либо в Adobe Photoshop, либо в Adobe Illustrator. При создании макетов в этих программах можно следовать нескольким правилам, которые позволят разработчику эффективно обработать макет в Blend.

Уже несколько очень хороших списков правил для стартапов было написано талантливыми и опытными людьми (здесь и здесь). Я хочу добавить еще один в коллекцию. Эти правила я вырабатывал последние четыре года. Если вы создаете компанию, я надеюсь, что это облегчит ваш путь.

Мы продолжаем публиковать статьи о разработке и производстве сложной современной электроники. В этот раз расскажем об изготовлении прототипов и опытных образцов. Любой проект включает в себя эту стадию, от ее результатов зависит дальнейшая судьба устройства — выход на массовое производство или отправка на доработку.
 
Рабочий образец воплощает в себе результаты работы инженеров, программистов, промдизайнеров и технологов. Его щупают, рассматривают и оценивают, сравнивая ожидаемое с действительным.
 
Зачем вообще нужны эти прототипы? Сколько штук их нужно изготовить в рамках проекта и сколько это стоит? Какие документы нужны для производства опытных образцов? Ответы на эти вопросы вы найдете под катом.
 

Всем привет.

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

Месяц назад я начал свое знакомство с IP-телефонией, а именно с Lync и Asterisk. И заметил следующую картину: в сети очень много интересных статей по практической стороне вопроса (как и что делать) и очень мало внимания уделено теории (в конце статьи приведены ссылки). Если Вы хотите разобраться с SIP, то извольте либо читать RFC 3261, либо одну из «этих толстых книг». Это, естественно, полезно, но многим хочется в начале изучить некую выжимку, а уж потом бросаться в омут с головой. Эта статья как раз для таких людей.

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

Одна из проблем нашего высшего образования в том, что в вузах учат много чему, и алгоритмам, и языкам программирования, и ООП, и даже паттернам проектирования. Но я еще ни разу не встречал, чтобы в вузах учили работать работу. Лабораторки не в счет. Спихнул – и забыл! Возможно, просто не везло.

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

Итак, про семь навыков…

Некоторое время назад промелькнула на Хабре вот эта статья о запуске игры. В ней автор делится своим опытом создания первой игры и публикации ее через издателя. На тот момент моя игра уже была выпущена и находилась в GooglePlay около месяца. Правда, я выбрал самостоятельный вариант публикации без какой-либо помощи издателей. А поскольку опыта в этой области у меня не было совсем никакого, то я сделал целый ряд ошибок, которые, по-моему, снизили и так небольшие результаты. Вот об этих ошибках, а также о детальной статистике на текущий момент, я и хотел бы рассказать…

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

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

Казалось бы, работа у IT-шников несложная — вагоны не разгружаем, землю не роем и уставать физически не должны. Однако о дичайшей усталости людей занятых интеллектуальным трудом приходится слышать чаще, чем хотелось бы. После того как я приехал в Москву 3 года назад — я почему-то начал дичайше уставать на совершенно ровном месте, и ни я, ни врачи не могли найти причину. После 2-х лет поисков тривиальная и легко исправимая причина нашлась, и на мой взгляд — в группе риска находятся практически все люди, занимающиеся интеллектуальным трудом. Ситуация усугубляется двумя народными обычаями.

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

1) Летом все ок, а зимой — апатия, ничего не хочется делать. Это любят называть сезонной «депрессией».
2) Утром все ок, а к вечеру на работе — мозги «не варят», ничего не хочется делать — только хабр и reddit листать. Приходите домой — и с дичайшей усталостью падаете в кресло. Сил хватает только лазить в интернете до ночи. Этот пункт — касается и работодателей, есть шанс, что люди вечером перестают работать не из-за своей лени.
3) Даже если вы просыпаетесь без будильника — вы не высыпаетесь.
4) Кофе и прочие стимуляторы — не дают бодрости, лишь делают вас злее.
5) Даже если вы спите «сколько влезет» — сны короткие и не запоминающиеся, или их нет вообще.
6) Вы замечаете, что даже 1 вещь вам иногда трудно удержать в голове. Мы можете забыть что вы сейчас хотели сделать.
7) Вы просыпаетесь уже с дичайшей усталостью
8) Вам кажется, что в комнате темно и все несколько не резкое.