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

Хватит менять размер окна браузера, хватит его насиловать! Готов спорить, вы не раз слышали это. Хорошо, возможно и не слышали. Но если вы профессионально занимаетесь разработкой адаптивных сайтов, вы понимаете о чем я: любое изменение DOM или правка CSS, и вы снова начинаете тянуть край браузера вперед, назад, тестируя изменения и просматривая ничего ли не сломалось.

Целью ваших движений является имитация экранов различных устройств.

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

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

Для тестирования я выбрал реально адаптивный сайт PajamasOnYourFeet.com, сайт построено на основе HTML5 шаблона, бесплатно предоставленным EGrappler.

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

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

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

Когда я работал программистом, ко мне нередко подходили с просьбой помочь сделать проект за долю. В некоторых я участвовал. Но очень мало проектов взлетело.
Со временем я стал менеджером проектов, а люди все так же подходят. И сами вокруг делают стартапы. Взлетают единицы.
Почему же?


Быстро разбогатеть и уплыть на собственный остров просто, увы, лишь в мечтах.

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

Именно мифы, которые заставляют мыслить неправильно, приводят к неудаче. И чем больше человек в них верит, чем меньше он способен изменять свое мышление, эволюционировать — тем выше шанс провала.

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

Зачастую вроде бы простые задачи верстки требуют сложной структуры HTML-разметки и использования CSS-трюков. Центрирование элементов или выравнивание контента может быть очень утомительным. Одна из таких задач — это выравнивание элементов верхней части сайта так, чтобы логотип был слева, а пункты меню — справа. Можно использовать float и position:absolute, а для выравнивания по вертикали — добавлять margin и padding разным элементам. Вроде бы ничего сложного. Но если сайт должен корректно отображаться и на мобильных устройствах, возникает много проблем.



Ниже описан лаконичный способ решения этой проблемы.

В подборке инструменты, плагины и другие полезности, облегчающие работу с Twitter Bootstrap. Предыдущая подборка.

Инструменты

Bootstraptor — подборка большого количества бесплатных и премиум тем, в том числе Starter Kit, на основе Bootstrap.

В этой относительно небольшой статье мы постараемся дать обзор изменений в интерфейсе Windows 8.1, на которые важно обратить особое внимание дизайнерам и проектировщикам приложений для Windows Store. В конце вы также найдете подборку докладов с конференции Build, полезных для дизайнерской аудитории (для разработчиков они, кстати, тоже полезны).

Справочный API 2ГИС разрабатывается уже 4 года. Появилось около 40 методов, которые возвращают достаточно крупные и иерархически сложные структуры в формате JSON и XML. Совсем недавно я решил поделиться накопленным опытом и выступить на конференции DevConf.
Одна из тем доклада вызвала наибольший интерес у участников — это использование JSON-Schema при тестировании формата выдачи API. В этой статье я расскажу, какие задачи решает этот подход, какие имеет ограничения, что вы получаете из коробки, а что идёт бонусом. Поехали!

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

Начать надо с главного. Я гедонист. Нет, правда! В хорошем смысле слова: сценарий «обколоться анашой» и тупеть для меня не очень интересен. Просто я думаю, что все в жизни должно быть классно и интересно. А если нет — сделай так чтобы было.
Этот текст я начал писать в ночном тайском автобусе, следующем с острова Пхукет в Бангкок. Одно из ребер графа Москва-Бангкок-Хошимин-Муине-Паттая-Пхукет-Панган-Самуи-Бангкок-Бали-Москва, растянутого во времени на 5 месяцев.



Одно важное замечание: я не сбегал, не валил, не заводил трактор.
Просто однажды осознал, что радость жизни теперь можно черпать большей ложкой, и эпоха офиса может быть сменена на хайлевел фриланс.
Что такое хайлевел фриланс? Это когда работаешь за нормальные 20-30 баксов в час; не общаешься с заказчиками-гопниками; не кидаешь, не ждешь кидалова; работаешь с полной отдачей меньше 40 часов в неделю (кто работает в офисе реальные 8 часов и не сгорает через полгода?); контрибьютишь в open-source проекты по мере надобности и заводишь свои… потому что хочется это делать!

На прошедшем неделю назад чемпионате мира по командному программированию ACM ICPC 2013 было 11 задач, одну из которых за отведённое время не смогла решить правильно ни одна из команд.

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

В этом году на ACM ICPC был 21 аналитик из Швеции, Нидерландов, США, Словакии, Беларуси и России. И 10 из них были из Яндекса. Все они в разные годы были призёрами ICPC. Специально для Хабра они разобрали все задания чемпионата.

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

Внимание, раздвоение истории!

Ветка 1
А к чёрту этот Модуль! Открываю текстовый редактор и пишу статью. Так как мысли лезут в голову сами, за день она легко делается. На следующий день, уже ни на что не отвлекаясь, пишу Модуль.
«Малодушно», скажете вы? Давайте рассмотрим альтернативное развитие событий.

Ветка 2
К чёрту эту Статью! Я мужественный программист и должен сначала закончить важное дело!
Целый день пытаюсь отмахиваться от мух посторонних мыслей. Стараюсь раскладывать Модуль на функции, а не на главы, и согласовывать интерфейсы, а не падежи. Итого, к концу дня едва начатый Модуль и чуть-чуть разрозненных записок по Статье, которые я всё-таки скинул в блокнот, чтобы выкинуть из головы.
На следующий день Статья забыта окончательно, и я спокойно доделываю Модуль.
На третий(!) день я пытаюсь вспомнить, что имел в виду в своих заметках по Статье. Но так как я от неё хорошо отгородился, получается так себе. Может быть, за этот день напишу. А может и нет, вдохновение то ушло.

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

Разумеется, не всё так просто. В таком поведении есть известные (и не очень известные) риски.

Доброго времени суток. Сегодня я бы хотел поделиться с вами интересным способом решения проблемы доступа к вашему серверу/ПК из-за NAT, используя IPv6 Tunnel Broker и бесплатные возможности сервиса CloudFlare.

Предисловие

Как известно, многим пользователям предоставляется доступ в интернет или с помощью динамического IP-адреса, или с помощью технологии NAT.

Если первые еще могут воспользоваться каким-либо Free DDNS сервисом, то вторым приходится сидеть, сложа руки, или покупать у провайдера заветный статический IP-адрес.

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

В хабратопике Фотографии рабочих мест хабражителей и… был один интересный комментарий от хабрапользователя hermit931

… Ах да — у меня не совсем доска, а из старого окна рама со стеклом ) разница не большая, только в весе :)

И в мозге сразу возникла мысль: «Зачем я выкинул старые деревянные окна при ремонте квартиры !» Мозг продолжил выдавать мысли: «Как сделать маркерную доску с наименьшими денежными затратами и наибольшей долговечностью и эффективностью».

Я поделился идеей с коллегой. Через пять минут спрашиваю: «Что ты думаешь о том, чтобы сделать маркерную доску». Как выяснилось, он за эти пять минут уже перечетал все хабратопики по этому поводу (параллельно этим занимался и я).

Мы с коллегой проанализировали все хабратопики по изготовлению маркерных досок своими руками и разделили их на две группы:

1) Маркерные доски по технологии: подложка + цветной фон + стекло

Контрастная и долговечная маркерная доска
Идеальная маркерная доска
Маркерная доска своими руками

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

2) Маркерные доски с применением самоклеящейся пленки или скотча на белой бумаге

Бюджетная маркерная доска
Маркерная доска

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

Хотелось совместить прочность первой группы и дешевизну второй. Кому интересно, что у нас получилось — прошу под кат.

Недавняя статья, сравнивающая русских разработчиков с иностранными навеяла. И мне есть что сказать по этому поводу.



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

По-моему, эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.

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

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

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

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

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

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

Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.

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

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

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

1) Отработал миллион часов на free-lance.ru
2) Заработал миллион на odesk.com
3) Нанял тысячу людей на русском фрилансе и расскажу как не оказаться кинутым.
4) Работаю пятый год на elance, odeske, freelancer и раскажу все о фрилансе за рубежом.

В офисе моей первой компании висело изображение с логотипом Nike и заглавными буквами JFDI. (JFDI расшифровывается как «Just Frickin' Do It» — «просто, блин, сделай это». Если не совсем очевидно, аббревиатура обыгрывает слоган компании Nike «Just Do It» — «просто сделай это»). Я уверен в том, что для успеха в бизнесе нужно быть в состоянии сделать много чего. Вы постоянно должны принимать решения, а информации никогда не хватает. Это парализует многих. Но не вас.

Переведено в Alconost.