Издательство Питер решило вспомнить о хорошей, но забытой книге Скотта Беркуна «Искусство управления IT-проектами, 2-е изд.»

Вот, что говорит сам автор о своей книге:

«С годами созидательного труда и сопоставления своего личного опыта с опытом других менеджеров, программистов и проектировщиков, я неплохо освоил искусство управления проектами, которое включает в себя подходы к руководству командами, работу над идеями, организацию работы над проектами, выдерживание рабочего графика, улаживание конфликтных ситуаций и достижение конкретных результатов даже перед лицом серьезных испытаний и неблагоприятно складывающейся обстановки. Несмотря на широкое толкование названия этой книги, большую часть своего рабочего опыта я приобрел в технической области, работая, в частности, в корпорации Microsoft. Я проработал в этой корпорации с 1994 по 2003 год, возглавляя команды специалистов, работающих над такими проектами, как Internet Explorer, Microsoft Windows и MSN. Несколько лет я проработал в группе совершенствования разработок корпорации Microsoft, отвечая за обучение и консультации команд в рамках всей компании, и довольно часто получал приглашения выступить с докладами на публичных конференциях, в корпорациях и университетах. Большинство советов, уроков и историй, приводимых в этой книге, являются плодами этого опыта работы. Хотя у меня за плечами богатое прошлое разработчика программного обеспечения и веб-приложений, при работе над книгой я расширил область исследований, обратившись к источникам и технологиям, выходящим за рамки разработки и управления. В книге содержится много полезных сведений для людей, принадлежащих миру бизнеса. Я убежден, что трудности в организации, руководстве, разработке и производстве имеют много общего, независимо от области деятельности. В процессе изготовления тостеров, строительства небоскребов, производства автомобилей, создания веб-сайтов и программных продуктов во многом приходится сталкиваться с одними и теми же трудностями, и эта книга написана в первую очередь о том, как эти трудности преодолеть.В отличие от некоторых других книг о руководстве проектов».

Естественным путем завершился опрос «Какая методология используется в вашем проекте». На текущий момент ответили 2,668 человек — огромное всем спасибо!

Удивительным образом снова победили “Через %опу” и “Как получится”: 58% в сумме. На выходных, когда лидеры уже определились, мы сели обсуждать эту ситуацию с нашим экспертом по управлению проектами Иваном Селиховкиным.

По ходу разговора Иван поделился интереснейшим концептом про патологические матрицы проекта, после чего мы а) заствили Ивана зарегистрироваться на Хабре (встречайте: selikhovkin) и б) решили записать отдельное видео про эти самые матрицы:



35 минут о том, что бывает не так в проектах — пять часто встречаемых шаблонов:

• Гипер-ТОП
• Нервный ПМ
• Расстрельный ПМ
• ПМ-ТОП
• Ненужный ПМ

А под катом — сводная таблица по методологиям с 2009 года

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

Мы отобрали 10 самых любопытных, на наш взгляд, вопросов в этой теме и снова заперли в студии Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП и нашего хорошего друга, чтобы он рассказал, что конкретно делать:



10 реальных ситуаций, которые удалось осветить — под катом:

Это первая из двух статей, рассказывающая о тестировании с помощью gremlins.js и grunt-gremlins. Первая статья — перевод официальной документации gremlins.js. Вторая — опыт внедрения gremlins.js в реальный проект при помощи grunt-gremlins.

Gremlins.js это monkey testing библиотека написанная на JavaScript, для Node.js и браузеров. С ее помощью проверяется надежность веб-приложений под полчищем гремлинов.

Kate: What are they, Billy?
Billy Peltzer: They're gremlins, Kate, just like Mr. Futterman said.

Когда-то мне доводилось участвовать в попытках внедрения Agile в команде, разрабатывающей ПО. В регулярных дискуссиях, стараясь, чтобы это внедрение не превратилось в карго-культ, я снова и снова цитировал пост в блоге Элизабет Хендриксон. Ему уже больше трёх лет, но мне он нравится, и я бы хотел представить вашему вниманию (и вашей борьбе с карго-культом) перевод этого поста.

В последнее время набирают популярность различные NoSQL базы данных. Эта статья начиналась как изучение особенностей графитовой графовой базы данных Neo4j. Но, в процессе подбора информации, мне захотелось систематизировать информацию о NoSQL решениях и о графовых базах данных, в частности.
В ходе этого небольшого исследования, были выбраны для подробного рассмотрения СУБД, успешно применяющиеся в области Web. И, поскольку в тегах присутствует «PHP», я выбирал СУБД, которые уже можно использовать с этим языком.

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

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

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

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

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

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

Так уж сложилось, что в наших проектах ведение технической документации полностью лежит на плечах разработчиков, по принципу: внес изменения в код проекта — актуализировал документацию. Сама документация представляла собой набор Word’овских документов, которая хранилась вместе с исходным кодом под VCS. Данный подход к организации разработки существовал долгое время, но пару лет назад мы решили озаботиться возможностью ведения документации проекта отличными от MS Office средствами.

Вчера вышла [весьма достойная статья про Web Components, и я понял, что не могу не поделиться тем опытом, что я накопил за последние восемь месяцев. Я не буду рассказывать о том, как работать с Веб Компонентами, я расскажу, почему. Поэтому тем, кто не знает об этом стеке технологий, стоит прочитать статью по ссылке выше.
Дело в том, что в июне вышла первая стабильная версия моей библиотеки CornerJS. Начавшись как автономная реализация директив из AngularJS, она постепенно превратилась в более простой — как в использовании, так и в реализации — аналог (неточный, да, я знаю) Пользовательских Элементов из спецификации Веба Компонентов.

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

Это замечательная, на мой взгляд, в реализации библиотека — я действительно считал ее основным инструментом в разработке, и в последнем проекте (видеопортале) она оказалась важнее jQuery: от него я мог бы отказаться, а от нее нет.

Но я, как человек, внедривший ее в нашу команду, и отказываюсь от нее — мы переходим на Mozilla X-tags для IE9+ сайтов и Polymer для IE10+ сайтов. К счастью, на моей памяти у нас был всего один или два проекта IE8+.

И в этом посте я расскажу, почему веб-компоненты — это не просто будущее веба. А единственное будущее веба.

Все животные равны, но некоторые животные равнее других. Скотный Двор, Джордж Оруэлл (оригинал).

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

(картинка сделана на основе хабра-статьи «Список скептика»).

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

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

Прочитать книгу можно на сайте, который мы специально для нее создали, следить за обновлениями можно по RSS и в твиттере. Проект хостится на GitHub Pages, а это значит, что все, кто хочет помочь в вычитке глав, исправить опечатки, или каким-то иным образом помочь проекту, может легко это сделать.

Сайт перевода
Репозиторий на GitHub

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



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

Но всё меняется, когда Java разработчики пишут SQL код.

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

Вторая часть довольно подробного и интересного изложения материала, касающегося кэша и его использования. Часть 1.

Автор, Mark Nottingham, — признанный эксперт в области HTTP-протокола и веб-кэширования. Является председателем IETF HTTPbis Working Group. Принимал участие в редактировании HTTP/1.1, part. 6: Caching. В настоящий момент участвует в разработке HTTP/2.0.

Текст распространяется под лицензией Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

От переводчика: об опечатках и неточностях просьба сообщать в личку. Спасибо.

Статья устарела, актуальную информацию ищите на сайте Warp9'а



Существует множество реактивных и около-реактивных библиотек для создания графического интерфейса на js: Angular, Knockout, React, RxJS… Спрашивается, зачем писать еще одну. Оказывается, во всех них, помимо фатального недостатка, есть еще несколько.

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

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

• предотвращение взлома веб-страниц за счёт нарастающей задержки или использования CAPTCHA;
• предотвращение офлайн-взлома путем применения достаточно медленной хеш-функции с индивидуализированной на уровне пользователя «солью»;
• защита хешей паролей.

Хочу предложить сравнительный анализ ответственности частного предпринимателя и наёмного работника. Огромное количество нашего брата «трудоустроено» как ЧП. И вроде бы даже в курсе, что это не совсем трудоустройство, и что есть немалые риски, но достоверно знают не многие.

Побудивший источник — весьма грамотный юрист, бизнес-школа. Именно эту тему (не применительно к программистам, а в целом) я имел возможность недавно прослушать в доходчивом изложении. Уточнение: речь идёт об украинских реалиях и законодательстве, а потому буду использовать украинский термин ФОП (все аббревиатуры в конце статьи), во избежание ошибок восприятия. Вероятно, в России весьма схожая картина; буду рад, если в комментариях прояснятся отличия по изложенным пунктам.

В этой статье я расскажу об одном из средств обеспечения версионности схем и управления миграциями БД — библиотеке Flyway. С поблемой версионности схемы базы данных рано или поздно приходится сталкиваться разработчикам любого приложения, опирающегося на СУБД. Увы, иногда эта проблема принимается в рассмотрение слишком поздно — например, если вопрос о внесении изменений в структуру базы встаёт, когда приложение уже находится в эксплуатации. Но и на этапе разработки контроль схемы базы данных причиняет не меньше проблем, чем все прочие аспекты версионности приложения: в отсутствие чёткой системы управления миграциями локальная, стендовая и эксплуатационная базы могут быстро «разъехаться», не предоставляя при этом никакой информации относительно своего текущего состояния.