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

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

Привет, %username%
Тут я хочу рассказать о том, как я настраивал кеширование на одном сервере, точнее VDS. Характеристики сервера: 2000MHz, 2GB RAM, 80Gb HDD, технология виртуализации — OpenVZ.
Было решено использовать Nginx версии 0.7.64. На сервере находилось около 200 сайтов. И несколько высоко нагруженных проектов. Вот эти самые проекты и давали ощутимые тормоза и нагрузку на сервер. Мы будем рассматривать DLE в этом примере.

В этом году в русскоязычном Delphi-сообществе было опубликовано огромное количество материалов. Можно было запросто пропустить что-то интересное. Я постарался собрать в одной публикации ссылки на наиболее интересные публикации 2009 года. Все публикации имеют прямое отношение к Delphi. Получилось довольно много. Большое спасибо любезным авторам!

Введение

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

Поговорим о рисках

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

Введение

Суть проблемы, рассматриваемой в данной статье заключается в том, что Grid объекты библиотеки ExtJS не предназначены для использования в контексте вложенности. В общем случае, такая задача редко становится перед разработчиком. И все же, иногда, как, например, в моем случае, с ней приходится сталкиваться. Ниже я попытаюсь поделиться накопленным опытом, и, возможно, окажу тем самым кому-нибудь неоценимую помощь, на что искренне надеюсь :). Итак, в добрый путь…

Вы стесняетесь показывать выполненную работу начальнику? А почему?

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

Годика два или три назад начал свой путь в роли программиста и всегда был страх и стеснения показать выполненную работу. Даже когда знал точно, что мой скрипт или программа работают хорошо, переживал, что директор(клиент) найдёт кучу ошибок. Со временем начал быть смелее и когда давали повод для исправления моих «произведений» считал это как плюс только для моего опыта. Почему? Мне человек говорит, где мне можно улучшиться! То есть не мне приходится искать, а люди сами мне говорят.

Встречал людей, которые радуются, когда исправляют кого-то они думают, что они становятся умнее, чем тот, кого исправили, но чаще всего всё идет наоборот. Антон Павлович Чехов очень чётко подметил: «умный — любит учиться, а дурак — учить». Не все учителя дураки, а только те кто сами не учатся, а стараются только учить других. Главное помнить, что тебе нужно понять, что от тебя требуется и сделаться всё что сказали, если нужно переспроси раз, если нужно второй, но ты будешь знать на 100% что ты делаешь всё правильно. Рассказывай как ты бы ты сделал, не бойся говорить, даже если ты потом узнаешь, что это не правильно, потому что нет человека который всегда говорит правильно.

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

Что называется, о наболевшем. На днях принимал я зачёт у студентов первого курса. На зачёт нужно было написать небольшую — 1-2 странички — письменную работу о том, как новоиспечённый студент видит себя в специальности. Забегая вперёд, скажу, что каких-то особых требований не предъявлялось. Ясности и живости мысли было бы достаточно.

С чем же я столкнулся?

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

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

update: Теперь есть электронные версии книг!

Начнём…

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

Ладно. Задайте себе вопрос — что уже интернет знает о Вас? Скорее всего, интернет о вас знает уже все, а что, как говорится, seen can not be unseen в глобальной сети. Теперь второй вопрос — как этим могут воспользоваться злоумышленники.

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

У вас есть блог? Твиттер? Страничка во вконтакте или фейсбуке? Вы активный пользователь форумов? Тогда мы идем к вам…

Я перечитал свой же текст и мне стало страшно. Серьезно.

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

Люди постоянно стараются уйти от риска, когда дело касается доходов и наоборот стараются рискнуть, чтобы уйти от потерь. Если вы дадите людям следующий выбор: “Получить гарантировано $500 или бросание монеты, чтобы получить $1,000″. Около 75% выберут гарантированную прибыль. А теперь рассмотрим противоположную ситуацию: “Проиграть гарантировано $500 или рискнуть на $1,000″. Здесь противоположная тенденция, 75% выберут риск.

У людей в головах отсутствует стандартизованная модель оценки рисков. Компьютер не увидит различий между 2-мя приведенными выше ситуациями – это всего лишь степень того, насколько вы предрасположены к риску, но люди видят. Данный факт не следует рассматривать как некий сговор. Когда он впервые был озвучен, он перевернул экономическую теорию. Данный факт получил название “теория перспектив”.

За последние 20 лет компания Microsoft сделала как никто много для пропаганды GUI-интерфейсов, а инструменты Visual Basic и Visual Studio кормят миллионов программистов по всему миру. Однако специалисты самой Microsoft зачастую предпочитают кодировать в обычном текстовом редакторе.

Об этом зашла речь на недавней конференции PDC в рамках секции о будущем программирования. «Людям нравится рисовать картинки в программе? Наверное, да, — говорит Дон Бокс (Don Box), который в Microsoft работает на созданием декларативных языков программирования и инструментов. — Но если вы выросли на программировании, как я, вы делаете это в текстовом виде. И мне кажется опасным, что мы теряем это».

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

Внимание, вопрос JS программерам, есть ли какие-то вещи, которые не нашли отражения в этом тесте?

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

Моя версия под катом.

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

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

REST (Representational state transfer) — это архитектурный стиль или свод соглашений для web-приложений и сервисов, основанный на манипулировании ресурсами и спецификацией HTTP. Впервые об этом заговорил Рой Филдинг (Roy Fielding) — один из отцов основателей HTTP (Hypertext Transfer Protocol).

Web-приложения зачастую игнорируют спецификацию HTTP и двигаются вперёд используя полюбившиеся возможности: GET и POST, 200 OK и 404 NOT FOUND. Так как используются программируемые web-приложения, со своими собственными API, то решение игнорировать спецификацию HTTP, может создать проблемы в дальнейшем. Как следствие — имеем множество приложений с интерфейсами GET и POST. Например интерфейс удаления пользователя: GET /user/1/delete против POST /user/delete {id=1}; в случае REST можно указать /user/1 это ресурс, а удаление HTTP метод DELETE.

Доброго времени суток, %username%.
Представляю твоему вниманию анонс Ample SDK, новой кросс-браузерной библиотеки интерфейса пользователя.

Познакомиться с проектом Ample SDK тебе будет интересно по следующим причинам:

• упрощает создание клиентских веб-приложений
• реализует стандартные веб технологии и API кросс-браузерно
• повторяет архитектуру веб-браузера (ничего нового учить не надо!)
• позволяет использовать SVG в HTML (также в Internet Explorer, хм!?)
• позволяет использовать XUL в любом современном браузере
• позволяет легко определять новые доменно-зависимые UI технологии
• проект с открытым (MIT/GPL) исходным кодом (на GitHub)

Для затравки, один и тот-же SVG Tiger документ отображенный в Internet Explorer 6 и Google Chrome 3:



Интересно?

Quicky — hi-end шаблонизатор, написанный на PHP отличающийся гибкой функциональностью, и в то же время, высокой производительностью. За основу взят синтаксис и функционал Smarty.

содержание:
— переход со Смарти, на Quicky
— — чем Quicky лучше Smarty?
— Quicky быстрее PHP-native?
— Quicky темная сторона силы.
— Комьюнити Quicky. (теперь все тут http://code.google.com/p/quicky/)
— Богатые возможности Quicky.
— Вместо заключения. Личное мнение.