Какой хороший программист наш Вася! Всегда опрятно одет, вежлив и предупредителен, хороший семьянин и душа компании. Что? Как он, собственно говоря, программирует? Хм… Постойте… А мы и не знаем. Никто никогда толком результатов его работы и не видел-то. Получается, Вася — не очень хороший программист? Ну ладно.

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

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

За долгое время работы в Яндексе нам удалось систематизировать все наши знания и огромный опыт в создании фронтенда веб-сервисов. Результатом этого осмысления и длительной работы стала первая Школа разработки интерфейсов, занятие которой шли в московском офисе Яндекса. Вся практическая часть обучения проходила в реальных проектах Яндекса. Теоретическая же состояла из лекций, которые читали ведущие разработчики интерфейсов Яндекса: Сергей veged Бережной, Михаил mishanga Трошев, Алексей doochik Андросов, Михаил azproduction Давыдов и другие.



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

Собственно гипотеза

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

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

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

При чем здесь фрилансеры?

Есть несколько слоёв при ответе на этот вопрос.

Различные реализации игры «Жизнь» описывались на Хабре уже неоднократно. В этой статье, в качестве продолжения этой темы, рассматривается ещё один её вариант: в качестве игрового поля используется регулярная решётка на плоскости Лобаческого. Описываются общие методы использования плоскости Лобачевского в программах и необходимые для этого математические приёмы.
Как возникла плоскость Лобачевского, достаточно известно. В позапрошлом веке господа Гаусс, Лобачевский и Бойяи, проживавшие примерно в одно время в разных странах тогдашней Европы, задумались, что будет, если отменить пятый постулат Евклида и заменить его на противоположную аксиому. Оказалось, что не случится ничего плохого, и никаких противоречий не возникнет. Заметная часть последующего изучения неевклидовой геометрии была посвящена выяснению того, кто из них у кого украл идею этой самой геометрии.
Менее известно, что несмотря на «отрицательный» способ определения неевклидовой геометрии (вместо того, чтобы сказать, что через точку проходит ровно одна прямая, не пересекающая данную, мы говорим, что таких прямых может быть сколько угодно), мы, тем не менее, получаем систему теорем и формул, не менее стройную, чем та, что есть в евклидовой геометрии. И одновременно, у нас есть гораздо большее разнообразие геометрических фигур, в том числе, разбиений плоскости на правильные многоугольники.

В этой статье я пошагово расскажу, как писать самый обычный, классический сапёр при помощи Html5 Canvas, AtomJS, и тайлового движка LibCanvas.

А также смотрите продолжение — "Изометрический сапёр на LibCanvas (html5)"

Привет, всем!

:before

Пытливость ума (да и не только) заставляет искать новые и лучшее решения в том или ином направлении. Это и привело меня на страницы блога некого @simurai. Возможно, кто-то уже знаком с наработками товарища «Самурая», с остальными же хочу просто поделиться интересными идеями псевдо-японского гуру. В этой статье хочу рассмотреть один из его проектов: BonBon — Sweet CSS3 Buttons (по желанию читателей, другие работы автора будут преданы вниманию в последующих статьях). Начальная цель: создание CSS-кнопок, которые приятно смотрятся, имеют гибкую настройку, и в это же время будут иметь максимально простую разметку.

Доброго времени суток! Сразу объяснюсь по поводу оформления поста: однажды, наткнувшись на статью о CSS-генераторах, меня не сильно порадовало безмерное количество информации и навигационных элементов в представленных генераторах, и еще больше — их пользовательский интерфейс! Возмутило то, что инструменты для работы со стилями — сами не выдержаны в рамках возможностей, которые они представляют… как так?!

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

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

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

Крис Тейлор, известный миру игрохитами Total Annihilation и Supreme Commander, явил миру свою новую разработку, пока что носящую рабочее имя Project Mercury. Игровая технология, которая легла в основу — strategic zoom. Впервые подобная технология была, если не ошибаюсь, применена в игре M.A.X. 2, вышедшей в 1998м году. Крис же выжал из нее все возможное и, благодаря ему, теперь «классические» RTS игры вызывают ощущение клаустрофобии, запертости в «маленьком экране».
И теперь Крис предлагает использовать эту технологию на «рабочем столе», называя его Infinite Desktop. О проекте лучше всего расскажет его автор:

Прогресс не стоит на месте, меняется все – наше представление о мобильных устройствах, они становятся тоньше, лечге, производительнее, меняются способы взаимодействия с ними, на смену клавиатуре и мыши пришли тач и сенсоры, на смену которым идет Perceptual Computing.
Что такое Perceptual Computing? Это новая технология, которая позволит пользователю взаимодействовать со своим мобильным устройством посредством голоса, рук, лица, т.е. более естественных для человека способов взаимодействия.

    Не так давно, просматривая глубокой ночью достаточно интересную заметку о игре на основе JS/Canvas (со своими ошибками и заблуждениями, которые были и у меня, что уж греха таить, понастальгировал всласть), я наткнулся на очередную порцию откровенно холиварных комментариев, после прочтения которых мир за окном стал серым и безрадостным, еда потеряла вкус, а любимый чай оказался несладким. И в тот момент то ли звезды сошлись, то ли срочных и важных багов и фич на вчера стало немного меньше, но я решил ввязаться в спор с достаточно резкими тезисами и вступиться за любимую технологию, которую так откровенно поливали непонятно чем. Так бы и осталось все это на уровне беспредметного перебрасывания пакетов с доводами через забор, если бы в ту же ветку не решил написать RussianSpy, и не об абстрактных попугаях, которых легче переписать в 3D, а о вполне конкретной задаче. И промелькнувшая фраза «Могу прислать ТЗ...» плавно намекнула на то, что вечер обещает быть интересным.

Что это?

Треугольник Серпинского

Треугольник Серпинского — один из известнейших фракталов, его построение — одна из первых лабораторных работ на рекурсию по соответствующим дисциплинам во многих ВУЗах. Выглядит фрактал следующим образом:

Треугольник Паскаля

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

И что с того?

Есть в треугольнике Паскаля интересная особенность.

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

Ниже представлен «проект NULL», тот самый костяк, с которого обычно все и начинается. У меня.

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

Эта статья предназначена для тех пользователей unity3d, что уже хорошо знакомы с самим движком, но ещё не обладают достаточной собственной базой знаний для того, чтобы писать без дополнительного сёрфинга по интернету, с целью поиска возникающих иногда фундаментальных вопросов. Чтобы сократить некоторым время на ресёч, расскажу несколько важных фишек, которые необходимо знать каждому unity программисту. Если у Вас возникают вопросы: как сделать чтобы у Вас не тормозило на чём-то послабее iPad 3, или Вы не знаете как удобно работать со спрайтами, как заставить музыку не прерываться при загрузке, или как обойти максимальный допустимый размер под android (50 мегабайт) и так далее, возможно Вы найдёте ответ в этой статье.

Статья затрагивает лишь проблемы мобильной разработки (IOS, Android). Все примеры только на C#.

Автор статьи не претендует на абсолютную категоричность и правильность предложенных решений.

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

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

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

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

Введение

Долгое время считалось, что динамический анализ программ является слишком тяжеловесным подходом к обнаружению программных дефектов, и полученные результаты не оправдывают затраченных усилий и ресурсов. Однако, две важные тенденции развития современной индустрии производства программного обеспечения позволяют по-новому взглянуть на эту проблему. С одной стороны, при постоянном увеличении объема и сложности ПО любые автоматические средства обнаружения ошибок и контроля качества могут оказаться полезными и востребованными. С другой – непрерывный рост производительности современных вычислительных систем позволяет эффективно решать все более сложные вычислительные задачи. Последние исследовательские работы в области динамического анализа такие, как SAGE, KLEE и Avalanche, демонстрируют, что несмотря на присущую этому подходу сложность, его использование оправдано, по крайней мере, для некоторого класса программ.

Формы состоят из самых разных элементов интерфейса. Если вы не знаете, как правильно с ними обращаться, вы можете сильно усложнить заполнение форм. Чаще всего ошибаются, применяя выпадающие списки (select menu).

Когда использовать

Иногда можно встретить выпадающие списки с 2 вариантами, иногда — с более чем 20. В обоих случаях это неправильно. Если у пользователя есть менее 5 вариантов выбора, следует использовать радиокнопки. Так выбор будет проще и быстрее, потому что пользователю нужно лишь взглянуть на варианты и один раз кликнуть. С выпадающим списком ему нужно нажать на него, найти подходящий вариант и кликнуть снова. Также другие варианты не видны, пока вы не нажмёте на выпадающий список. Если их меньше 5, лучше наглядно показать их в форме в виде радиокнопок — пользователи смогут быстро их просмотреть.

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

1. А сколько займет сделать этот раздел (дается ТЗ из одной строки)?

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

Менеджеру: поймите, что программист строит в голове модель будущей системы. По одному предложению нельзя смоделировать приложение. И только ваша вина, если вы не потрудились уточнить ТЗ (это ваша работа, кстати) у заказчика, а хотите сразу назвать ему срок (и цену). Потому что оценка с потолка невозможна — вроде как ответить на вопрос «сколько времени займет покрасить комнату неизвестной площади?».

2. Ты же ОБЕЩАЛ сделать за два дня, а прошла неделя! (моют мозг по сроку из пункта 1)

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

Менеджеру: ничто так не демотивирует, как обвинение в некомпетентности и лжи. Постарайтесь давать точное ТЗ и бить задачу на простые кусочки, в чем программист с удовольствием поможет (если хорошо попросить). Тогда можно будет более точно управлять сроками.

Эпиграф: Зарплата у меня хорошая, но маленькая!

Глядя на то, как появляются и исчезают в черновики вместе с комментариями и обсуждениями статьи о найме и удержании сотрудников, я тоже решил рискнуть.
Я хочу поспорить с тезисом о том, что деньги не мотивируют и высказать свои аргументы в пользу высокой заплаты.
Вот тезисы, которые я хочу раскрыть немного подробнее в статье.
1. Высокая зарплата не мотивирует. А вот низкая зарплата демотивирует сама по себе.
2. Высокая зарплата отрезвляет, так как хорошо понимаешь, что на такую позицию быстро найдутся желающие.
3. Высокая зарплата затрудняет переход в другое место.

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

Недавний доклад Гарри Бернхардта на CodeMash оказался довольно популярен (прим. пер.: в том числе и на хабре). В докладе он шутит по поводу некоторых особенностей поведения ruby и javascript.
Вряд ли я смогу вас убедить, что есть какой-то смысл в том, на что жалуется Гарри. Тем не менее, надеюсь, я смогу вам объяснить, почему javascript ведёт себя именно так.