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

Многие из вас наверняка заметили, что я пишу книгу о Zend Framework. Недавно я закончил черновики двух глав: «Архитектура приложений на Zend Framework» и «Понимая Zend Framework». В первой главе объясняется архитектурный шаблон Model-View-Controller (MVC) и причины, по которым он стал стандартом де-факто для веб-приложений. Во второй исследуется связь MVC с компонентами Zend Framework, их структурой и взаимодействием.

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

Эта сторона фреймворков никогда не привлекала особого внимания. И все же именно она лежит в основе целого класса проблем в тех приложениях, которые пытаются использовать MVC по образу и подобию фреймворков для веб-приложений. Более того, попытки донести идею модели до других разработчиков нередко напоминают битье головой о стену. Я не хочу сказать, что все разработчики тупые или не понимают саму идею, просто никто из них (вне зависимости от того, работают они с PHP или нет) не связывает модели с той областью, которая наделяет их смыслом — принципами объектно-ориентированного программирования.

Рассказ пойдет о 2D играх от третьего лица (вид сверху). В основном это шутеры, но и стратегия будет тоже затронута. Для простоты сравнения и понимания мы возьмем наших любимых «котяток». Да, да, именно коты нам хорошо в этом помогут.

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

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

Кто-то вчера шутил, а кто-то занимался реально полезными вещами. Как например болгарский разработчик Мартин Ангелов, опубликовавший впечатляющий обзор JS библиотек:
http://tutorialzine.com/2013/04/50-amazing-jquery-plugins/
Настоятельно рекомендуется к обозрению.
PS Куда-то пропал тип топика «Ссылка» :(

Друзья, рады объявить, что с 1 апреля совместно с Национальным открытым университетом «Интуит» мы запускаем бесплатную online-школу по разработке приложений для Windows 8. Если вы еще не умеете программировать под Windows 8, то это как раз то, что поможет вам научиться.

Записаться на учебный курс можно тут: aka.ms/w8school

Курс длится 6+3 недели и включает лекции, online-консультации, лабораторные и курсовые работы. Лекции и консультации проводят сотрудники Microsoft Россия (департамент стратегических технологий).

Сервис цифровой дистрибуции Steam от компании Valve становится всё более популярным среди игроков. По состоянию на январь 2013, через Steam распространяется более трёх тысяч товаров, на которые действуют ежедневные, срединедельные и скидки на выходные дни, а количество зарегистрированных аккаунтов превысило 60 миллионов.

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

Объекты, классы, конструкторы

ECMAScript, будучи высоко-абстрактным объектно-ориентированным языком программирования, оперирует объектами. Существуют также и примитивы, но и они, когда требуется, также преобразуются в объекты. Объект — это коллекция свойств, имеющая также связанный с ней объект-прототип. Прототипом является либо также объект, или же значение null.

В JavaScript нет привычных классов, но есть функции-конструкторы, порождающие объекты по определенным алгоритмам (см. Оператор new).

Прототипное делегирующее наследование

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

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

JavaScript отличается от многих других «объектно-ориентированных» языков программирования тем, что в нём объекты есть, а классов — нет. Вместо классов в JavaScript есть прототипные цепочки и некоторые другие хитрости, которые требуют времени на осмысление. Перед профессиональными программистами в других языках при переходе на JavaScript встаёт проблема быстрого вхождения в его объектную модель.

Этот текст написан для того, чтобы дать начинающему или эпизодическому разработчику на JavaScript представление о способах создания объектов в JavaScript, от простого «структурного», как в языке C, к более «объектно-ориентированному», как в C++/C#/Java.

Статья может быть рекомендована как новичкам в программировании, так и бэкенд-программистам, пишущим на JavaScript только эпизодически.

Автор статьи — Joe Armstrong, разработчик Erlang

Я, как программист-старожил, люблю иногда вспоминать свою молодость …

Когда, в далеком 1967, я только начинал учиться программировать, я выбирал между языками Fortran и Algol. Про Algol ходило множество слухов, но практически никакой полезной информации нельзя было найти, так что я начал с Fortran.

На написание одной программы в среднем уходило 3 недели:

неделя 1 — написание программы на бумаге и отправка в компьютерный центр, где мне делали перфокарты;
неделя 2 — проверка перфокарт, и загрузка их в компьютер;
неделя 3 — получение и анализ результатов.

Когда компилятор доходил до первой синтаксической ошибки в программе, — он останавливался, и это отбрасывало меня обратно в самое начало, к первой неделе. Для исправления 10 ошибок в программе могло потребоваться 30 недель!

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

Добрый день, уважаемые хабражители. Дело в том, что совсем недавно я натолкнулся и примкнул к одному очень интересному для меня проекту. Группа энтузиастов, фанатов симуляторов автоперевозок, разочаровавшись в игре «Дальнобойщики-3», решили создать нечто свое, знакомое из детства. Проект носит название «Hard Trucker».Если вас заинтересовало, прошу под кат.

Это первый пост из блога Surfingbird, который я выношу в общие хабы алгоритмов и искусственного интеллекта; честно говоря, раньше просто не догадался. Если интересно, заходите к нам, чтобы прочесть предыдущие тексты, – я не знаю, что произойдёт, если просто добавить новые хабы к постам несколькомесячной давности.

Краткое содержание предыдущих серий о рекомендательных системах:

• рекомендательные системы: постановка задачи;
• user-based и item-based коллаборативная фильтрация;
• SVD, часть I;
• SVD и базовые предикторы;
• SVD на Perl;
• оверфиттинг и регуляризация;
• теорема Байеса и наивный Байес;
• LDA (Latent Dirichlet allocation, тематическое моделирование).

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

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

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

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

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

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

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

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

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

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

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

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

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

Крис Парнин (Chris Parnin) из технологического института Джорджии решил восполнить этот недостаток и опубликовал чрезвычайно насыщенную статью со ссылками на различные исследования по этой теме.

Для начала, несколько фактов, которые относятся ко всем работникам интеллектуального труда. Задача, прерванная по ходу выполнения, занимает в два раза больше времени и содержит вдвое больше ошибок, чем та же задача, которая выполнялась без прерывания (Czerwinski:04). Офисные сотрудники вынуждены отвлекаться при выполнении 57% задач (Mark:05). Опросы говорят о том, что сотруднику требуется в среднем 15 минут, чтобы вернуться в нормальный ритм после того, как его отвлекли (vanSolingen:98).

Посвящается Энди Рубину, Рику Майнеру, Нику Сирсу и Крису Уайту.



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

Для представителей последней группы, непонятным образом оказавшихся на Хабре:

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

• timeline.verite.co — создание интерактивного таймлайна на примере хронологии выпуска версий Android, бесплатно;
• easel.ly — хороший и тоже бесплатный помощник для создания инфографики.

Сейчас огромную популярность набирает текстовой редактор Sublime Text 2. Я же в давние времена перешел на Notepad++ и много лет им активно пользовался, радуясь и восхищаясь. И когда стали появляться слухи, что Sublime теснит Notepad++, то решил проверить и попробовать на него перейти. Но, к сожалению, обнаружил, что много фишек, которым мне так нравился Notepad++ (не все идут в исходных настройках) я не вижу, несмотря на обилие новых других интересных возможностей. И было решено попробовать настроить Sublime так, чтобы им можно было пользоваться также, как и Notepad++ (с плагинами), имея попутно возможности Sublime Text 2, коих нет в первом редакторе. И да, Sublime Text 2 настраивался в Windows 7.

Скажу сразу, всю DOM-модель мы строить не будем, а лишь рассмотрим ее элементы и как с ними работать при помощи jQuery. Статья рассчитана на начинающих или тех кто хочет вспомнить как можно строить элементы «на лету», надеюсь кому-то это будет полезно.
Большинство веб-разработчиков сталкивается с необходимостью вставить какое-либо содержимое из js, возможно это ajax или событие. Но никто не задумывается о том что с вашим кодом возможно кому-то придется работать. И часто даже в очень известных плагинах можно встретить код такого типа:

var content = "<table>"
for(i=0; i<3; i++){
    content += '<tr><td>' + 'result ' +  i + '</td></tr>';
}
content += "</table>"

$('#table').append(content);

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

Эрик Липперт — ветеран Microsoft, проработавший в компании 16 лет и стоящий за разработкой VBScript, JScript и C#.

На прошлой неделе в комментариях к одной из статей разгорелся спор о роли низкоуровневой оптимизации в программировании, и я вспомнил относящуюся к этому статью Эрика. Она была написана в конце 2003, и хотя реалии с тех пор несколько изменились — принципы остались теми же самыми. Можете мысленно заменить ASP и VBScript на PHP, JavaScript, или на другой скриптовый язык по вашему вкусу.

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

---

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

Например, за семь лет в Microsoft я получил десятки вопросов, аналогичных по своей сути этому, заданному в конце 1990-х:

У нас есть код на VBScript, и в одной часто вызываемой функции мы определяем оператором Dim несколько переменных, которые нигде в функции не используются. Не замедляется ли каждый вызов функции из-за объявления этих переменных?

Какой интересный вопрос! В компилируемом языке, таком как Си, объявление локальных переменных общим размером n байт всего лишь вычитает n из указателя стека при входе в функцию. Если n будет чуть больше или чуть меньше, затраты времени на вычитание никак не изменятся. Наверное, в VBScript точно так же? Оказалось, что нет! Вот что я написал автору вопроса: