Привет!
Какое-то время назад на Хабре была вводная статья в CMMI (Модель CMMI).
Мне повезло лично участвовать в процессе получения организацией 3 уровня этой модели. Хочется рассказать о том, как это происходит на практике.

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

FPS начал падать даже на весьма производительных системах… Проблема была типична для всех флэш-игр — большое количество векторной графики. Как вы понимаете, векторная графика — это весьма ресурсоемкая штука. Ведь при рендере плееру приходится заново рассчитывать разнообразные хитрые кривые и т.п., что явно проигрывает по скорости работе с растровой графикой. При чем — проигрывает на порядок (а то и несколько порядков).

По старой доброй традиции в зубы был взят Google и начался поиск решения…

Думаю многим верстальщикам известно решение, которое заставляет IE рисовать скругленные уголки: «curved-corner» (или border-radius.htc).

В этой статье я расскажу, как избавиться от ошибок «Invalid argument» при его использовании, а также как в разы ускорить его работу.

Любовь к HTML5 продолжает вдохновлять Поля Айриша. Во-первых, он подарил нам Modernizr, а сейчас он объединился с Divya Manian для создания шаблона HTML5, который использует передовые техники, чтобы Вы могли начать использовать его в своей практике.

Он, в сущности, является хорошей отправной точкой, состоящей из HTML и CSS, предлагающим также и структуру папок, которая работает. Но созданным с учётом многих лет передового опыта профессионалов в разработке клиентской части. Загляните в исходные тексты, чтобы почувствовать, что находится внутри. А если вы думаете, что этого слишком много, просто удалите лишнее.

Здравствуй, Хабр.

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

Разбирая код очередного проекта внутри тега head наткнулся на интересный код:

<!--[if lt IE 9]>
<script src="http://ie7-js.googlecode.com/svn/version/2.1(beta3)/IE9.js"></script>
<![endif]-->

Только одно слово «IE9» меня пустило в замешательство. Первое что пришло мне в голову — это то, что при помощи этого .js кода браузеры под печальным клеймом Internet Explorer можно заставить работать используя свойства многообещающего IE9. Больше всего я ожидал что будут доступны свойства CSS3.0, но не тут-то было!

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…

Введение

В этом топике я хочу представить вам, дорогие читатели, пересказ вебинара от человека, чьё имя не нуждается в представлении. Для того, чтобы изложить часовой вебинар в виде небольшого топика, мне пришлось значительно ужать комментарии автора, поэтому я сознательно не помечаю топик как «перевод». В этот раз Стив МакКоннелл решил поделиться с нами своим опытом в виде коротких тезисов, в которых он отражает самые страшные ошибки при оценке трудоёмкости разработки программного обеспечения. В 1998 году читатели журнала Software Development назвали Стива одним из самых влиятельных людей в индустрии разработки программного обеспечения на равне с Биллом Гейтсом и Линусом Торвальдсом. Стив — автор книги «Software Estimation. Demystifying The Black Art» — одной из самых популярных книг в области оценки трудоёмкости разработки ПО. Надо признаться, что вебинар был проведён относительно давно (июнь 2009 года), но информация, представленная там, совсем не устарела. Сам топик будет построен следующим образом. Заголовки будут достаточно точно переведены из презентации, которую показывал Стив, а в остальном я постараюсь отразить только основные мысли, чтобы не перегружать топик. Если кто-то посчитает, что ту или иную мысль я излагаю неправильно — милости прошу в комментарии, можно будет меня поправить.

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.

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

Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.

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

Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.

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

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

Совершенно случайно набрёл на одно интересное видео под названием Situating Personal Information Management (PIM) Practices within an Organization, почитал документ(создатели PIM подошли к этой проблеме основательно — исследования, тесты, теории, мне кажется, некоторые даже защитили кандидатские и докторские по этой тематике) и оказалось что те guidelines для организации хранения информации и быстрого доступа к ней, которые изложены в статьях, я уже давно и успешно использую в своей повседневной работе. И появились они у меня, как вы понимаете, не от хорошей жизни.
Так уж получилось, что работая ПМом, количество проектов у меня не опускалось ниже 5 и стабильно держалось в диапазоне 5 -10. Проекты были в основной своей массе небольшие, где то 3-5 месяцев длительностью и 2-4 разработчиков (ну и плюс сетевые администраторы, тестеры в проектной команде). Но когда к этому богатству добавился production support и maintenance и количество важных писем перевалило за 50-70 в день, пришлось задуматься насчет эффективного структурированного хранения проектной информации, её поиска, напоминаний о запланированных событиях. Далее описание что и как получилось...

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

Я бы хотел сегодня привести очень интересный отрывок из его дневника. Сегодня модно писать о том, как многое успевать, как быть эффективным, ка организовать бизнес и т.д. и т.п. К сожалению, как заметил Стивен Кови в своей книге «7 навыков высокоэффективных людей» (сам бы в жизни не читал по причине такого названия, но друг очень рекомендовал, прочитал книгу, очень доволен) сегодняшняя литература об управлении и личной эффективности сводиться к простому выписыванию рецептов решения стандартных проблем. Что-то типа аспирина на все случаи жизни. Редко встретишь книгу или статью затрагивающую глубинные мотивы, принципы внутренней жизни и целостности человека. Но сейчас не об этом… Хочу поделиться отрывком из дневника Франклина. Этот человек много достиг, поднялся с низов общества не имея официального образования, уверен, что много можно почерпнуть из его жизни.

Мечта многих моих друзей и знакомых, чтобы у них было больше времени. На что, вопрос второй. Кому-то время нужно на семью, кому-то на любимую работу, кому-то на отдых. Но время, это тот ресурс, которого не хватает у нас всех. Мне удалось спрессовать время и получить в сутках, вначале лишние десять минут, потом час, потом еще несколько часов. За десять лет, время спрессовалось так, что в моих сутках около 48 часов. За неделю я успеваю сделать столько, сколько многие люди за две, три, а то и месяц. Без ущерба личной жизни, качеству работы, не с помощью бессонных ночей и постоянных авралов. В небольшой заметке постараюсь изложить основные положения той системы, которой придерживаюсь, чем она помогает мне, какие слабые и сильные стороны в ней есть. Чтобы изложить все приемы и уловки, понадобится не один материал, рассматривайте эту заметку, как вводную. Если вам понравится, и вы скажете, что желаете прочитать продолжение, то оно появится.

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

Время это не только физическая величина, но и психологическая

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

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

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

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

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

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

С этим всем пониманием давайте взглянем на то, что я называю «пирамида стратегии в Сети».

Не знаю, на сколько эти мысли полезные и/или капитанские, если что — скажете :) Но такое я нигде не встречал, к сожалению.

Засыпая и размышляя над очередной идеей, которой потребовался бы хелпдеск/багтрекер подумал: ведь заставлять пользователей пройти через регистрацию, чтобы запостить баг/фичреквест — бесчеловечно. С дрйгой стороны, Анонимусы — тоже не всегда хорошо. И что делать?

Суть вкратце: идеальная форма регистрации — форма логина.
Подробнее и с картинками под катом.

Задача прибивания футера к низу страницы обмусолена с ног до головы. Она неплохо решается для футера фиксированной высоты. А вот для случая, когда высота футера зависит от его содержимого, методов не так много. Либо это очевидное решение на javascript. Либо подгонка для этого элементов, изначально для того не предназначенных. Я, конечно, о таблицах. Хочу предложить способ, который тоже имеет свои недостатки (обо всем ниже), но недостатки эти другие, и, следовательно, может подойти тем, кому первые два не подходят.

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

Само понятие модульной сетки, за последние несколько лет стало чрезвычайно модным. В первую очередь у дизайнеров. И во-вторую очередь у верстальщиков.

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

Немного про модульные сетки

Модульная система вёрстки — система вёрстки, при которой основой композиции полос и разворотов становится модульная сетка с определенным шагом (модулем), одинаковым или разным по горизонтали и вертикали. По мотивам Википедии.

В этом топике вы найдете немного ностальгии, каплю гнева и килограмм реверс-инжиниринга. Посвящается тем, кто знаком с программой «Звукозапись» не понаслышке :)

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

Шли годы. Железо становилось мощнее, а ОС функциональнее. Но «Звукозапись» не менялась. Даже в Windows XP она оставалась такой же, как и тогда. Пришло время обновить железо. 3 гигабайта оперативной памяти — раньше и мечтать о таком не приходилось. Этого уж точно должно хватить всем! Так и было, пока дело не дошло до той самой «Звукозаписи». После попытки записать небольшой звук программа невозмутимо возразила, что ей недостаточно оперативной памяти.