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

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

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

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

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

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

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

Статья посвящена основам и является детальным их описанием. Следующие статьи с подробными примерами будут основываться на ней. Данная статья построена на принципах, которые мы обсуждали в «Где наша бизнес-логика, сынок?» («Dude, where's my business logic?»).

Наши пользователи следят за спецпредложениями авиакомпаний и дешевыми перелетами, каждому интересно своё направление, пунктов вылета и прилета — тысячи, пользователи хотят одновременно следить за несколькоми городами, странами или регионами. Появилась задача — как предоставить удобный механизм подписки? Без долгого тыканья в мульти селект, без кнопок «Добавить пункт вылета». Ответ выглядит так —

Решением стал контрол из Фейсбука и Контакта — пользователи знакомы с ним, а значит не нужно объяснять как он работает. Осталось скрестить его с django.

Человек с ником Ilap под впечатлением живых обоев на android, создал плагин для compiz, имитирующий эти обои. Примечательно то, что, по его словам, до этого у него не было опыта разработки ни на opengl, ни плагинов для сompiz.

DevPoint 2 успешно состоялся. Если кто не в курсе DevPoint — это конференция, посвященная ведущим технологиям разработки, тестированию и управлению проектами. Конференция прошла в Новосибирске 2-го октября, 3-го и 4-го октября шли мастер-классы.

Судя по мнениям участников и докладчиков, DevPoint 2 — это первое ИТ-мероприятие подобного уровня, которое проходит в Сибири. Больше не обязательно ехать в Дефолт-Сити, чтобы послушать признанных российских экспертов в области информационных технологий и пообщаться с ними в неформальной обстановке. Теперь это можно сделать и в Новосибе — на DevPoint.

Среди докладчиков — автор поискового движка Sphinx Андрей Аксенов (Воронеж), создатель HTTP-сервера nginx Игорь Сысоев (Москва), вице-президент Гильдии менеджеров программных проектов Александр Орлов (Санкт-Петербург) и другие ИТ-гуру. Отдельная благодарность нашим новосибирским докладчикам. И еще: рекомендую обратить особое внимание на доклад-отжиг Аксенова "Прекращаем писать код".

Когда есть свободная минута, открываю любую методику наугад, внимательно перечитываю и «медитирую по мотивам».





Несколько дней назад ZotovSergey упомянул про свою коллекцию различных методик повышения продуктивности мышления (принятия решений) и отрывочных записей на эту тему.
По просьбам, которые здесь последовали, он открыл свой блокнот «Zen Engineering» в Evernote для публичного доступа.

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

Тем, кто непосредственно связан с организацией работы в команде и использует коллективный способ принятия решения, следует знать о таком явлении как «групповые эффекты»

Generation Next
За последний год произошла небольшая революция в мире СУБД, связанная с появлением безсхемных (безструктурных) СУБД таких как Apache CouchDB. В этих базах данных используется другой подход нежели в реляционных БД. Они достаточно быстро становятся популярны среди Web-разрабочиков из-за своей гибкости, простоты и легкой интеграции с современными технологиями такими как JSON.
В данной статье изложен краткий обзор MongoDB, одной из новых поколений безсхемных СУБД, которая получила большое внимание разработчиков.

Хорошие новости. В октябре, 2-го числа в Новосибе состоится конференция разработчиков DevPoint 2. Конференция посвящена ведущим технологиям программирования, веб-разработки, тестирования и управления проектами.

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

На первом DevPoint'е было так клево, что мы решили не останавливаться на достигнутом и провести второй.

Стояла задача динамического визуального отображения реакции на действия пользователя со стороны системы.
Другими словами: изменилось какое-то состояние объекта — вывести сообщения об удачном завершении сохранения изменения в базе/системе.
Написание плагина не заставило себя ждать...
 

Как разработчик, вы сидите на золотой жиле. Вы осознаете это?

Нет, серьезно, на @#$% золотой жиле! Никогда в истории не существовало возможностей так легко создать что-то с нуля, с маленьким или отсутствующим начальным капиталом и маркетинговой моделью, ограниченной только вашим воображением.

Подумайте о крупнейших сайтах, которые вы постоянно посещаете: Facebook, Twitter, Flickr, Foursquare, или даже Google — все они были созданы разработчиками, у которых была лишь идея. Было ли это легко? Черт, нет. Но это могло быть сделано только в наше время. Так, черт побери, почему вы просиживаете день за днем, работая на кого-то?

На этот раз мы решили рассказать о замечательном продукте, который мы используем в нашей работе. Речь пойдет о Celery — «distributed task queue». Это распределенная асинхронная очередь заданий, которая обладает широким функционалом. В нашем конструкторе сайтов нам часто приходиться запускать асинхронные с точки зрения ответа пользователю задачи. На хабре, к сожалению, не много информации по данному продукту, а он заслуживает отдельного упоминания, это мы и хотим исправить.

Итак, что же умеет Celery:

• Выполнять задания асинхронно или синхронно
• Выполнять периодические задания(умная замена crond)
• Выполнять отложенные задания
• Распределенное выполнение (может быть запущен на N серверах)
• В пределах одного worker'а возможно конкурентное выполнение нескольких задач(одновременно)
• Выполнять задание повторно, если вылез exception
• Ограничивать количество заданий в единицу времени (rate limit, для задания или глобально)
• Routing заданий (какому worker'у что делать)
• Несложно мониторить выполнение заданий
• Выполнять подзадания
• Присылать отчеты об exception'ах на email
• Проверять выполнилось ли задание (удобно для построения Ajax приложений, где юзер ждет факта завершения)

Заинтересовало? Просим под кат.