Удаленная работа положительно сказывается на производительности. Это подтверждает недавнее большое исследование, результаты которого в формате интервью опубликовал «Harvard Business Review» (HBR) — гарвардский научно-популярный журнал, посвященный вопросам управления бизнесом. В интервью Николас Блум (Nicholas Bloom), профессор экономики Стэнфордского университета рассказывает о влиянии рабочей обстановки на производительность труда сотрудников. Интервью провел Скотт Беринато (Scott Berinato) — старший редактор HBR.

Суть исследования

Николай Блум вместе с коллегой Джеймсом Лиангом (James Liang), аспирантом Стэнфордского университета и соучредителем китайского сайта Ctrip, посвященного путешествиям, предложили сотрудникам колл-центра Ctrip поработать на дому. Эксперимент длился 9 месяцев. Половине добровольцев было разрешено работать дистанционно, в домашних условиях, остальные сотрудники остались в офисе в качестве контрольной группы. Данные о производительности работников колл-центра, собранные в ходе исследования, показали, что по сравнению с операторами, которые трудились в офисе, «надомные работники» не только чувствовали себя счастливее и реже увольнялись, но и оказались более продуктивными.


Значительное улучшение показателей. Группа добровольцев, работавших на дому, приняли больше звонков, чем их коллеги, которые остались в офисе

В этой статье я хочу немного поговорить об авторском праве и свободных лицензиях на ПО. Текст является результатом самостоятельного выбора лицензий и их применения к своим проектам.

Статья будет полезна тем, кто хочет:

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

Несколько недель назад в PhpStorm 8 (доступной в рамках программы раннего доступа / Early Access Program) была добавлена поддержка популярной CMS WordPress. Свежий билд PhpStorm 8 EAP можно загрузить бесплатно прямо сейчас, так что все описанное в данном обучающем материале уже можно попробовать, а мы в свою очередь будем благодарны обратной связи в нашем багтрекере.

Исчерпывающую информацию о поддержке WordPress в PhpStorm можно найти в англоязычном материале WordPress Development using PhpStorm. В этом посте мы расскажем о самых важных функциях, включенных в поддержку WordPress в PhpStorm.

На данный момент поддержка включает:

• интеграцию PhpStorm с WordPress для существующих проектов и новых плагинов;
• настройку рабочей среды для разработки под WordPress;
• настройку стандартов оформления кода WordPress и следование им;
• поддержку хуков (включая автодополнение для параметров регистрирующих функций; навигацию от функций, регистрирующих хуки, к вызовам хуков; и другие функции);
• поиск документации на WordPress.org прямо из редактора;
• интеграцию с инструментами командной строки WordPress WP-CLI.

Статью с обзором ситуации с микроэлектроникой в России я закончил утверждением, что сейчас в России есть технические возможности для создания любых военных микросхем (если не считаться с ценой). Однако и в комментариях к той статье, и во многих других — всех больше волновал вопрос отсутствия (на уровне погрешности измерений) производства чисто-коммерческих (гражданских) высокотехнологичных продуктов. Этот вопрос волновал и меня, потому я постоянно мучил вопросами всех, кто так или иначе связан с высокими технологиями и бизнесом в России.

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

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

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

Добрый день, уважаемые коллеги. В этой статье я бы хотел рассказать о своем аналитическом понимании различий паттернов MVC, MVP и MVVM. Написать эту статью меня побудило желание разобраться в современных подходах при разработке крупного программного обеспечения и соответствующих архитектурных особенностях. На текущем этапе своей карьерной лестницы я не являюсь непосредственным разработчиком, поэтому статья может содержать ошибки, неточности и недопонимание. Заинтригованы, как аналитики видят, что делают программисты и архитекторы? Тогда добро пожаловать под кат.

Это руководство для WPF-разработчиков, стремящихся добиться максимально чёткой картинки в своих приложениях. Графическая система WPF до мозга костей векторная, но конечным результатом её работы по-прежнему является растр. Если не уделить этому факту должного внимания, можно столкнуться с различными сортами «мыла» — паразитными артефактами растеризации. В такой ситуации важно не терять присутствия духа, причины их возникновения вполне рациональны, а методы борьбы достаточно просты и эффективны.

Я собираюсь сделать Java-веб-приложение (да, это будет Java, по некоторым причинам, которые сейчас озвучивать не хочу). В процессе работы, я оцениваю кучу J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container фреймворков.

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

Давайте представим, что я решил сделать шкафчик для специй.

Сегодня на глаза попался старый вопрос "Почему работодатель предпочитает нанимать веб-разработчика в офис?": habrahabr.ru/qa/22292. Вопрос был задан еще в 2012 году, но, на мой взгляд, ситуация с тех пор не сильно изменилась.

Коллеги, тут есть серьезное недопонимание, которое давно пора устранить.

Многие, как мне кажется, представляют себе фрилансера примерно так:

• Приходит на какую-то отдельную небольшую задачу, выполняет ее и уходит.
• Работает над несколькими мелкими проектами одновременно. Либо имеет постоянную работу, а фрилансером просто подрабатывает в оставшееся время.
• Его не беспокоит проект в целом. Только то, за что он отвечает.
• Огораживает себя техническими заданиями. И из-за каждой новой плюшки может возникнуть конфликт.
• Работает когда хочет. С ним сложно связаться.

Доброго времени суток!

Я бы хотел рассказать Вам о своих личных ощущениях о игрострое после года работы над собственным проектом.

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

Еще раз напомнюсь, эта статья — лишь ощущения от знакомства с игростроем, и рассказ о своем небольшом опыте.

Не мог пройти мимо топика "Вопросы на собеседование middle/senior iOS Developer" и статьи "Собеседование разработчика". Хочу предложить альтернативный или дополнительный подход к собеседованию разработчиков.

Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»

Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.

К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.

Что ты предлагаешь, чувак?

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

Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!

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

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

Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).

Большая часть аудитории Хабра регулярно пишет код. В текстовом редакторе или IDE. И сколько бы не было в нем окошек и менюшек, а сердце любого редактора — это компонент (widget), который редактирует и подсвечивает код.

Больше года назад на Хабре был цикл статей от namespace про компонент QScintilla (1, 2, 3), и моя статья с его критикой. Получилась некоторая недосказанность. Ясно, что все плохо, но не понятно, что делать.

Сейчас я написал свой велосипед компонент под названием Qutepart, и у цикла есть продолжение.
Эта статья расскажет о том, как устроена подсветка синтаксиса в моем проекте: какие проблемы возникали, и как они решались. Она про подходы, а не про специфику конкретного GUI-инструментария. Если интересно заглянуть «под капот» текстового редактора, добро пожаловать под кат.

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

Как один из самих молодых магазинов приложений Windows Store, по идее, должен был бы впитать в себя самое лучшее из Google Play и App Store. Но на практике оказалось, что этого не случилось.

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

Налоговая декларация (Tax Profile)

Для того чтобы начать продавать платные приложения не обходимо заполнить налоговую декларацию. Форму можно заполнить в онлайн: отправлять обычной почтой или факсом ее никуда не нужно. Вся соль не в этом. После заполнения формы вы сможете увидеть следующий живописный вид:


Попробуйте догадаться, что означает надпись: «Ваша налоговая декларация заполнена неправильно. Пожалуйста, исправьте ошибки».

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

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

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

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