Профильный ресурс Modern Workplace Learning обработал данные 7,5 тыс. анкет своих посетителей и подписчиков и выяснил, каким способам обучения (в рамках своей профдеятельности) отдают предпочтение люди по всему миру. В итоговом исследовании есть детальные разбивки по возрасту, полу, региону, размеру компании (включая фрилансеров).



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

Социальные науки и UX-исследования: ближе, чем вы думали

Начнем с вопроса. Можно ли сделать действительно качественный IT-продукт без пользовательской аналитики? Да или нет? Кто выбрал «да»? Если вы и так знаете, что на самом деле нужно вашим пользователям, дальше можете не читать. Сэкономите свое время. И деньги на аналитику. Правда, зачем оно вам?

Вот что делать с человеком, который на все упреки и призывы к грамотности
отвечает одним аргументом — «Мне по***»?
— Крик души

Не любо — не слушай, а врать не мешай!
— Поговорка

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

Предлагаю вашему вниманию перевод и адаптацию статьи Сьюзан Вайншенк — «The Psychologist’s View of UX Design».
Предупреждаю, что статья может содержать много «банальных» утверждений. Однако, считаю, что это ничуть не умаляет её общеобразовательной ценности.

… Все вы, наверное, слышали притчу о слепцах и слоне:

Недавно участвовал в разработке одного проекта — фото конкурса. По задумке, рейтинг фото альбомов должен формироваться из суммы всех публикаций в социальных сетях: Facebook, Вконтакте, Twitter. Т.е. общий рейтинг фотоальбома расчитывается:

Рейтинг фотоальбома = кол-во «Share» в Facebook + кол-во «Сохранить» в Вконтакте + кол-во «Retweet» в Twitter

На макетах, вид кнопок несколько отличался от предоставляемых социальными сетями плагинов, формируемых функциями api. В частности вид счетчиков:

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

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

Итак:

• количество лайков будем получать от REST сервисов каждой социалки
• кнопки рисуем свои и обрабатываем событие click

Задача

По опыту других рельсовиков известно, что для хостинга rails-проектов нужен VDS хостинг.
Знающие люди подсказывают, что из openVZ и Xen, лучше Xen.

Условия задачи: найти недорогой VDS-хостинг варианта Xen.

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

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

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

Каковы же варианты сбора пожертвований для своего любимого детища?

Это одна из моих любимых статей Стива Павлины о саморазвитии. Несмотря на широкую популярность статьи, найти ее на Хабре мне не удалось, решил поделиться с Вами.

Хорошо вставать до рассвета,
такая привычка способствует здоровью,
богатству и мудрости.
Аристотель

«Жаворонками» рождаются или становятся? В моём случае совершенно точно имело место становление. Когда мне было чуть больше двадцати, я редко ложился спать раньше полуночи и почти всегда вставал поздно. Обычно я не начинал свои дела до конца обеда.

Но через некоторое время я уже не мог не замечать явную зависимость между успехами и ранним подъёмом, даже в моей личной жизни. В те редкие случаи, когда я вставал рано, моя производительность почти всегда была выше, и не только утром, но и в течение всего дня. Кроме того, я был в прекрасном расположении духа. Будучи человеком, который активно добивается своих целей, я решил выработать привычку рано вставать. Я просто поставил будильник на 5 утра…

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

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

В данном посте затронул ключевые моменты и ошибки в вопросах

1. Как мы сидим
2. На чем сидим
3. Зарядка
4. Спорт

Данным постом мы открываем рубрику «Переводы» в нашем блоге. Почему мы решили открыть такую рубрику? Дело в том, что сотни специалистов, работающих в Mail.Ru Group, для решения стоящих перед ними задач ежедневно прочитывают множество интересных статей и постов на форумах. Некоторые из них кажутся нам интересными, и мы считаем своим долгом перевести их на русский и поделиться этими ценными знаниями с Хабражителями.

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

Я расскажу вам о том, кто же такой комьюнити-менеджер (КМ), чем он занимается и каковы отличия, например, от SMM-специалиста (social media manager). Также вы узнаете об азах управления сообществом и нескольких приемах, которые используют КМы в своей работе. Полезен материал будет и командам разработчиков как небольших, так и крупных проектов, в которых планируется работа с комьюнити. Специально для менеджеров проектов есть раздел о важных ошибках, которые в свое время допустили многие продюсеры в рамках управления игровым проектом. В общем, читать рекомендую всем, кто так или иначе связан с игровой индустрией или просто ею интересуется.

Чуть более двух лет назад я опубликовал статью Другое видение скучных GTD планировщиков через призму RPG игр, в которой описал свою старую идею про совмещение работы над software проектами и элементов RPG игр.

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

Топик тогда собрал 100500 комментов (в основном «супер! хочу!»), а особо заразительные собрались в команды и стали воплощать идею в жизнь. Так что же было сделано за эти два года?

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

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

Но самое главное это то, что авторы интересуются нет ли у вас своей команды из 3-4 человек. Если у вас нет своей команды, Chuck Eesley и Amin Saberi обещают помочь собрать команду по стране проживания, интересам и сфере, в которой вы работаете. В любом случае, авторы просят заполнить необходимые данные до 18 марта.

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

Сразу оговорюсь: это просто статья о том как написать статью. С какого боку тут всякие сокращения будет понятно чуть позднее.

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

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

Предисловие

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

Введение

У меня за спиной огромный опыт работы с PHP, но сейчас я работаю Rails разработчиком. Огромную сложность для большинства людей, которые пытаются освоить что-то новое — это сам процесс обучения. Когда вы владеете каким-либо языком или фреймворком и знаете его вдоль и поперёк, переход на что-то новое не представляется необходимым.

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

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

Методика общеизвестна и называется она — планирование.

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

Я очень люблю паттерны. Нередко применяю идеи из одной сферы в другой — так, в тайм-менеджменте отлично работает принцип программирования KISS (keep it simple, stupid), равно как и DRY (don't repeat yourself).



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

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

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

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

А как же писать планы, которые работают?