Настороженно отношусь к непрофильным топикам, но решил написать этот по следующим причинам:

• У жонглирования есть своя теория — стройная и математически привлекательная!
• Мы живем не только работой. Жонглирование — отличное развлечение и разминка после долгого сидения за компом.
• В пятницу приятно немного расслабиться и почитать не очень серьезные статьи. К тому же, будет чем заняться на выходные, особенно если у вас не было определенных планов.

Теория

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

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

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

Здравствуйте, уважаемые читатели хабры.

Хочу вынести на суд широкой общественности идею системы премирования (мотивации) сотрудников.
Метафизика идеи заключается в привнесении рыночных отношений в производственные процессы.
По легенде, эта идея впервые была предложена в 1982 году Советским специалистом по организационным технологиям Валерием Водяновым и использовалась при строительстве Калининской АЭС.
По той же легенде были получены выдающиеся результаты и коллектив строителей превратился в некое интегральное «мы», показав рекордную производительность. Почитать про это можно здесь.
Более того, столь необычное решение проблемы мотивации и сопутствующие события вдохновили Александра Проханова написать книгу «Ангел Пролетел».

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

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

Частенько читаю Хабр и заметил что в последнее время появились Дайджесты новостей по многим тематикам, таким как веб-разработка на php, разработка на Python, мобильные приложения, но не встретил ни одного подборки по популярному сейчас направлению, а именно анализу данных и big data.

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

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

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

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

Маркетинга нет...

                                                    Артемий Лебедев
                                                    $115. О маркетинге
                                                    11 июля 2005

                                                               Маркетинга не существует.

                                                    http://www.artlebedev.ru/kovodstvo/sections/115/

Парадокс. С каждым днем мы в нашей компании все более погружаемся в интернет-маркетинг. И тем не менее я согласен с Лебедевым в тезисе из эпиграфа. Нету там ничего твердого и основательного. Во что погружаемся — непонятно. Немного психологии, немного аналитики, немного веб-технологий — такой жиденький супчик. На голову вылить — в волосах не застрянет. На толковое образование не тянет. Если человек говорит “я по образованию маркетолог”, сразу возникает ощущение платного вуза из подворотни и неуместных понтов. А в письмах предсказуемо не хватает запятых, зато много псевдо-деловых фраз типа “пантон доллара”, “надо брифовать” и “сбрасывайте ваши варианты, мы будем смотреть с руководством”.

На одном из моих первых тренингов один из присутствующих менеджеров задал вопрос:

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

Когда меня называют экспертом, надо понимать эффект. Мне становится очень приятно, я отрываюсь от земли, мозг отключается и дальше начинается словесный поток. (Если хотите поставить эксперимент, подойдите к докладчику на любой конференции после доклада и скажите что-нибудь вроде: “Спасибо, очень понравился Ваш доклад. Вот Вы, как эксперт, как считаете...” Дальше можно спрашивать что угодно, но человек будет уже не с вами. Мы поэтому просим никогда не обращаться к нам как к экспертам.)

В общем, меня понесло…

Вводная часть

Прошлый мой материал “Краткая инструкция по работе с web-дизайнером (для менеджера проекта)” вызвал неоднозначные отзывы и отличную ответную статью (взгляд с другой стороны) “Краткая инструкция о том, как надо работать с web-дизайнером (взгляд дизайнера)”.

Прочитав обе статьи, вы сможете составить адекватное собственное мнение на заданную тему.

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

Введение

Я работаю веб-дизайнером. Какое-то время назад я подрабатывала фрилансером, сейчас работаю в небольшой студии. У нас нет менеджера проектов, поэтому, зачастую, я сама выступаю этим самым менеджером, по совместительству. Опыт общения с самыми разными заказчиками у меня достаточно большой. Статья «Краткая инструкция по работе с web-дизайнером (для менеджера проекта)» вызвала у меня шквал эмоций и бурю негодования, потому что именно таких заказчиков я всегда старалась избегать. В этой статье я попробую описать, как в идеале должна проходить работа заказчика и дизайнера.

С удовольствием приму критику и выслушаю мнения «другой стороны».

Уверен, многих технарей посещала идея создания своего бизнеса. Вот и у нас в определенный момент все звёзды сложились так, что казалось — это беспроигрышный вариант: сильная техническая команда, откуда ни возьмись появились менеджеры, готовые продавать наши услуги, есть даже пара проектов на старт. Грех не попробовать. И мы рискнули. Фактически всё надо ставить с нуля.

В статье будут даны рекомендации по работе с WEB-дизайнерами. Исполнение этих рекомендаций даст значительное повышение качества работы, увеличение производительности труда и сохранит нервные клетки.

В каждом из пунктов будут живые примеры и ссылки на полезные, бесплатные инструменты.

В идеале, в комментариях вы оставите свои советы, замечания к статье, ссылки и примеры.

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

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

Сразу хочу сказать, что все книги на английском. Часть из них можно найти на русском, но без английского на уровне чтения и прослушивания подкастов будет тяжко – на русский клевые вещи об управлении продуктами переводят медленно и нехотя. Второй момент – чтение книг из этого списка не сделает из вас менеджера продукта. Как и книжка С++ за 21 день не сделает из вас С++ разработчика. Просто уровень вхождения в окологуманитарные профессии пониже, и это иногда создает напрасные иллюзии.

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

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

Приветствую всех!

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



Мой опыт, на основании которого я сделал описываемые выводы, возник из примерно 6-летней в общей сумме работы с людьми, желавшими или думавшими, что желают, обучиться программированию. В процессе работы велись как групповые, так и индивидуальные занятия с обучающимися (возрастом от 16 до 26 лет), величина групп была в среднем около 11 человек, по несколько групп параллельно.

Коити: Порог срабатывания сборщика мусора в Ruby — 8 МБ. Почему используется такое маленькое значение?
Matz: Потому что 20 лет назад я работал на машине с 10 МБ памяти.

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

В статье речь пойдет об одной из наиболее сильно влияющих на производительность частей языка Ruby — сборщике мусора, алгоритмах его работы и улучшениях, внесенных в его работу в последних версиях языка. Речь пойдет о наиболее распространенной, «канонической» реализации Ruby — так называемой MRI или CRuby.

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

Devise — это ruby-гем, предоставляющий возможности для аутентификации в rails-приложениях. Devise работает в связке с гемом Warden, который в свою очередь предоставляет сам механизм для аутентификации в rack-базированных ruby-приложениях. Основные особенности Devise описаны ниже:

• основан на Rack;
• является законченным MVC-решением, основанным на Rails;
• разрешает вход в систему по нескольким моделям одновременно;
• основан на модульности: использует только то, что вам действительно необходимо.

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

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

Наш ответ: “НЕТ! Бумага сакс! Нужно ломать стереотипы”.
Вот уже год как мы в учебном центре “Урансофт” вместо традиционных сертификатов и свидетельств о прохождении курсов заводим онлайн-профайлы на слушателей. Как мы к этому пришли и какие результаты получили — читайте под катом.

Привет всем. Хочу рассказать о том, как и зачем мы организовали студию для видеопродакшена у себя в офисе. Немного о себе. Увлекаюсь фотографией, снимаю репортажи и музыкантов. С недавних пор я работаю менеджером по маркетингу в ИТ-компании: фото- и видеосъемка — одна из моих приоритетных задач. Маркетингом и PR я раньше не занимался, но, со слов моего руководителя, опыт в фотографии плюс большой стаж работы в традиционных архивах и знание технологий оцифровки и хранения документов сыграли решающую роль в предложении мне этой вакансии.

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

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

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

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

Вы всегда должны улучшать три своих качества: компетентность, скорость и осведомленность.