Я прочитал пост «13 причин не быть управленцем» и хочу написать ответ.

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

Таким образом, к примеру, есть мозг художника, и он не будет математиком. А математик часто не может писать гениальные стихи, и так далее. Бывают гении, типа Леонардо да Винчи, но это исключение.

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

Поэтому универсальных советов нет, каждому нужно искать свое дело.

Это было предисловие, а теперь про плюшки работы управленцем.

Итак, что в управлении проектами круто.

1. Масштабируемость
Как управленец, я могу строить управленческие структуры, рабочие группы, и суммарный результат во много раз больше, чем если бы я сам кодил. При этом масштабируемость бесконечна, насколько хватит способностей.

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

А сейчас, в период между Рождеством и Новым Годом, когда особенно обострена склонность к углублённой рефлексии, приходит понимание того, что, знай я некоторые «инсайдерские» подробности управленческой деятельности заранее – сделал бы совсем другой выбор лет эдак семь назад.

Вот поэтому и родился этот немного хаотичный и очень разнокалиберный список моментов, которые очень хотелось бы передать куда-то обратно, примерно в 2005 год – дайте знать, если кто-то вдруг уже научился это делать! А пока, может быть кто-то найдёт некоторые из перечисленных ниже пунктов не до конца очевидными, или даже полезными для себя; было бы приятно осознавать, что удалось помочь кому-то сделать более осознанный выбор профессии – или просто о чём-нибудь важном задуматься.

Перед Новым годом на хабре были опубликованы два топика (первый, второй) о создании «Солнечной системы» на HTML5 Canvas. Бегло прочитав их и изучив результаты профилирования я удивился тому что такая простенькая программа так неэффективно работает. Вооружившись Notepad++ решил проверить всё ли так плохо, написав свою реализацию.

ТЗ остаётся всё тем же. 12 планет, период обращения первой — 40 секунд, каждой последующей на 20 секунд дольше. Изначально планеты имеют случайное расположение на своих орбитах. У каждой планеты есть описание, которое отображается при наведении курсора на неё. При клике на планету она останавливается. Если курсор находиться над орбитой — подсветить её. Всё это должно работать в Opera 12+, IE9+, Chrome и FF.

— Я не хочу ничего читать, давай результат!
— Держи: жмяк

Здравствуйте. Сегодня на глаза попался пост о курсе программирования под Android на сайте Linux Foundation, а вместе с ним — и немало комментариев о том, что хотелось бы видеть и перевод этих уроков. Поскольку я сейчас, после четырех лет разработки под микроконтроллеры, начал изучать и программирование для мобильных устройств, то параллельно решил сделать перевод первой части урока.

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

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

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

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

Теоретически процесс TDD должен выглядеть так:

1. Написали падающий тест, прогнали rspec, убедились что тест не проходит (красный)

2. Написали кусок кода, прогнали rspec, убедились что тест проходит (зеленый)

3. Отрефакторили, убедились что все хорошо и тесты не падают.

4. Отправили код в продакшн

DRY(Don’t Repeat Yourself) — один из краеугольных принципов современной разработки, а особенно в среде ruby-программистов. Но если при написании обычного кода повторяющиеся фрагменты обычно легко можно сгруппировать в методы или отдельные модули, то при написании тестов, где повторяющегося кода порой еще больше, это сделать не всегда просто. В данной статье содержится небольшой обзор средств решения подобных проблем при использовании BDD-фреймворка RSpec.

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

Всем привет!

Предлагаю сделать простую проверку безопасности на ваших серверах.

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

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

С Новым Годом!

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

Файл проекта из среды UML моделирования представлял собой базу данных формата SQLite3, однако некоторую часть информации в этой БД среда хранила в виде сериализованных в BLOB поля объектов. Формат сериализации был текстовый, но не совместимый ни с одним из известных, такими как XML, YAML, совсем отдаленно напоминал JSON. Использовать существующие в природе парсеры было невозможно.

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

Erlang on Xen позволяет запускать приложения Erlang без операционной системы, на голом гипервизоре Xen. От момента запуска VM до начала работы приложения проходит всего 50 миллисекунд — в 100-1000 раз меньше, чем нужно для запуска привычного сочетания Linux+Erlang, а размер образа машины составляет лишь около 1 Мб. Это позволяет добиться практически мгновенного масштабирования, вплоть до запуска экземпляра VM после того, как пришёл запрос от клиента.

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

Лежащая в основе Erlang on Xen виртуальная машина Ling показывает производительность, сравнимую со стандартной для Erlang VM BEAM (Bogdan/Björn’s Erlang Abstract Machine).

Для перемещения элемента по экрану есть два основных способа:

• CSS 2D-преобразования и translate();
• position:absolute и изменение top/left.

Крис Койер недавно писал, почему лучше и логичнее использовать translate (это быстрее, и свойство position имеет большее отношение к вёрстке, а не к визуальным эффектам и анимации, в отличие от translate).

Я хочу расширить его ответ и привести несколько хороших примеров. Я записал скринкаст, в котором помощью Chrome DevTools timline рассматриваю различия между этими подходами с точки зрения производительности, особенностей рендеринга и композитинга на GPU.



Если вам нужна сокращённая текстовая версия — продолжайте читать.

Что такое хелпдеск? Система управления заявками пользователей, личинка сервисдеска, первый шаг эникейщика на пути к ITIL, бла-бла-бла…



Литература, посвященная вопросу организации системы управления инцидентами (заявками пользователей, проблемами в ИТ — называйте, как хотите) делится на две категории. Первая включает в себя технические низкоуровневые мануалы, посвященные, в основном, тонкостям настройки конкретных решений. Такие работы могут рассказать в подробностях, как добиться прироста производительности в WonderDesk величиной 0.001% под SuperSQL v.0.0001 alpha, но, как правило, ничего не говорят о том, зачем вообще нужен этот WonderDesk, и, главное, что с ним, существенно ускоренным, потом делать.

Вторая категория написана для… Даже не знаю, для кого. Я бы сказал, что для богов, но им, вроде, инструкции не нужны. «Нужно пересмотреть саму парадигму взаимодействия паттернов бизнес-процессов в рамках концепции корпоративных ценностей с целью повышения уровня зрелости...» Ага, пересмотрел (предварительно подглядев в словаре значения всех этих непонятных слов), дальше что? Как сделать, чтобы мое «пересмотренное понимание» заставило пользователей писать заявки, эникейщиков — обрабатывать их, а уровень зрелости — повышаться?! Предлагаете «постепенно внедрять лучшие практики управления»? Да, как же их внедрить, если я простой эникейщик и ничем не управляю?!

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

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

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

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

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

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

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

В данной статье изложены размышления и фантазии на тему «как можно было бы скрестить Erlang и PHP, чтобы случилось вселенское счастье», а не описание готовой технологии или продукта. Впрочем, мы намерены это реализовать, скорее всего, в форме open-source проекта, если, конечно, уважаемая хабра-аудитория не отговорит :) Собственно, одна из главных задач этой статьи — понять, насколько идея интересна и потенциально полезна широкому PHP-сообществу. Кстати, некоторые из проблем, обсуждаемых в статье, справедливы и для других популярных скриптовых языков (тут я подразумеваю Ruby и Python), так что предлагаемое решение, возможно, будет актуально и для них.

Не так давно мне стало любопытно, насколько сносно современные браузеры поддерживают HTML5 и я не нашел лучшего
способа, чем написать простейший 2D платформер. Помимо удовольствия от разработки игрушки и улучшения навыков в использовании JavaScript, в ходе развлечения кропотливой работы был накоплен определенный опыт и эмпирическим путем были найдены основные грабли, на многие из которых мне пришлось наступить. В этой статье я попробую кратко и с примерами резюмировать то, что вынес для себя из проделанной работы. Желающих создать свое высокопроизводительное JavaScript приложение, эффективно работающее с графикой, прошу под кат.

Этот алгоритм является улучшенным алгоритмом поиска пути A*. JPS ускоряет поиск пути, “перепрыгивая” многие места, которые должны быть просмотрены.  В отличие от подобных алгоритмов JPS не требует предварительной обработки и дополнительных затрат памяти. Данный алгоритм представлен в 2011 году, а в 2012 получил высокие отклики. Что из себя представляет данный алгоритм и его реализацию можно прочитать дальше в статье.

Заканчиваются курсы по MongoDB для разработчиков и архитекторов баз данных от 10gen, компании разработчика MongoDB.
Финальный экзамен отправлен на проверку и хотелось бы поделиться впечатлениями от курса и полученной информации, рассказать о плюсах и «минусах» MongoDB.

Введение

На Хабре не раз писали об инвентаризации, но для меня не нашлось ничего полезного. Почему? Ответ прост: передо мной была поставлена задача: автоматизировать процесс инвентаризации товаров магазина. Лежащие на полках склада товары не отвечают на пинги, не могут по команде сами о себе собрать статистику и отправить их на сервер. При этом магазин не виртуальный, и даже не маленький розничный магазинчик, где за час можно пересчитать все руками, блокнотом и ручкой. Речь идет о довольно крупной торговой сети, продающей товары весьма различных направлений.



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