Недавно в комментариях в очередной раз попалась мне на глаза легенда про Чёрную Команду, рассказанная Томом ДеМарко в свой книге «Человеческий фактор». Книга замечательная, а легенда дурацкая. Так и хочется пожелать, чтобы ДеМарко всю жизнь пришлось работать с такими тестировщиками!

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

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

Итак, хотите знать, как положительным образом влиять на программистов?

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

Так получилось, что завершение перевода этой статьи Майкла Болтона удачно совпало с появлением на хабре заметки Натальи Руколь «Почему тестирование — это тупо и скучно?», которая вызвала достаточно бурное обсуждение. Эта статья призвана в какой-то степени объяснить, почему одним тестирование кажется скучным, а для других людей это самое интересное занятие в мире.

Когда мне было лет двадцать с небольшим, я решил быстро научиться вкусно готовить. Нашел книгу «Гурман за 60 минут» Пьера Фрейни, и пошел читать.

Выяснилось, что мистер Фрейни описывал не технику, а свою философию приготовления еды.

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

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

Продолжая тему рассуждений про карьеру, мы с хабраюзером eagleson записали новое видео: «Карьерное плато».



Коротко и по делу (всего 18 минут) обсудили следующие темы:

• Динамика ИТ-специалиста: рост, рост, рост, ЗП, семья, ипотека…
• Почему так, где движение?
• С любого плато можно улететь: нужно строить самолет!

Подарите себе 18 минут времени, чтобы задуматься над вопросам «Сколько лет до вашего плато?» и «Строите ли свой самолет?»

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

Продолжая эту тему, предлагаем вам некоторые рассуждения в ключе «Что делать дальше?»



Очередные 18 минут, в рамках которых мы поговорим про:

• Накопление экспертизы
• Выход с плато
• Простой способ взлета
• Тренерство и консалтинг

А еще там есть прикольный самолетик :)

Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

В этом топике мы в общих чертах рассмотрим процесс реализации непрерывной интеграции на примере TeamCity Enterprise 6.0 EAP (build 15400) и обратим внимание на применении инструментов рассмотренных в прошлой теме: Обеспечение качества программного продукта.

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

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

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


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.

Начиная с версии 5.1 mySQL поддерживает горизонтальное партицирование таблиц. Что это такое? Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям.. На нижнем уровне для myISAM таблиц, это физически разные файлы, по 3 на каждую партицию (описание таблицы, файл индексов, файл данных). Для innoDB таблиц в конфигурации по умолчанию – разные пространства таблиц в файлах innoDB (не забываем, что innoDB позволяет настраивать индивидуальные хранилища на уровне баз данных или даже конкретных таблиц).

Как это выглядит?

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

Итак, сегодня мы соберём генератор миниатюрок на базе любимого народом веб-сервера — nginx-а. Что примечательно, сделаем мы это без единого гвоздя, т.е. без единой строчки кода, не считая конфигурации.

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

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

Поехали

Программисты с Etsy.com поделились опытом, как им удалось эффективно решить задачу по пакетному ресайзингу фотографий с 1,5 МБ до 3 КБ (после смены дизайна оказалось, что старые превью-окошки не вписываются в новые шаблоны страниц). Задача не такая банальная, как кажется. Дело в том, что Etsy.com — крупный интернет-аукцион, и количество изображений различных товаров превышает 135 млн штук.

Ради шутки они прикинули, сколько займёт эта работа вручную в «Фотошопе». Если на каждую фотографию отдать по 40 секунд, то выходит 170 лет непрерывного труда. Затем они начали считать, можно ли отдать пакет в облако EC2 и во сколько это встанет. Посмотрев на получившуюся сумму, программисты решили поискать другой способ.

В итоге им удалось завершить обработку 135 млн фотографий всего за 9 дней, задействуя четыре 16-ядерных сервера. Средняя скорость обработки составила 180 изображений в секунду.

Существует цепочка в мозгу: мы напишем юнит тесты, затем эти тесты нам расскажут если мы что-то сломали, затем они нам почту будут отправлять о том, что проект поломался.
Это ничто иное, как иллюстрация непрерывной интеграции (Continious Integration) нычне крайне модного направления гибкой разработки. Единственный недостающий элемент цепочки — «КАК». Ниже коротенький рецепт, как бы отвечающий «очень просто».

Угроза отказа в обслуживании (Denial of Service, DoS) является особой категорией сетевых атак, чьей целью является недоступность того или иного веб-сервиса для легитимных пользователей. Атака реализуется за счет создания массы обращений на сервер-жертву (victim). Такие атаки легко распознаются, и сам инициатор атаки обнаруживается и блокируется достаточно просто. Поэтому сейчас в такие игрушки никто не играет, а новое поколение атак носит распределенный характер (Distributed Denial of Service). Инициатор атаки использует зараженные системы, расположенные по всему миру, чтобы одновременно скрыть свое местонахождение и сделать атаку более мощной и результативной. Тому, как происходит борьба с атаками, а также новому способу удаленной борьбы с DDoS и посвящен этот пост.

Обмен файлами всегда привлекал людей, для этого собственно и был изобретен протокол BitTorrent.

Большинство торрент трекеров написано на PHP, хотя встречаются и такие, которые написаны на C# языке, но для ознакомления мы будем использовать именно PHP.

Давайте рассмотрим что из себя представляет трекер.

Данная статья не является чем то сверхестественным и подойдет скорее для тех, кто начинает изучать
Zend Framework. Так уж получилось что сам я начинал изучение с версии
1.7, но незадолго после начала познания данного инструмента меня забрали в армию, и год я программированием не занимался. Сейчас до возвращения в родные края остался месяц, а так же появилось свободное время.
В начале изучения какого либо инструмента, как я заметил по себе всегда хочется иметь его под рукой, чтобы сразу же при возможности
поковыряться а не перечитывать предварительно кучу документации.
Так у меня было с Zend Framework, когда он был еще версии 1.7
Пришлось перечиать несколько статей и пересоздать кучу каталогов,
чтобы настроить рабочий Zend Framework проект. Собственно данная статья является своего рода переводом статьи Zend Framework Quick Start | Create Your Project для версии Zend Framework 1.10.5
С некоторыми исправлениями и примечаниями.
Прочитав ее я думаю вы с легкостью создадите рабочий Zend Framework
проект и сразу же перейдете к изучению на практике.

В общем то, если все же кому то статья покажется по вкусу, возьмусь
за перевод всех статей серии Quick Start.

Итак, поехали…

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

На сегодняшний день диапазон цен на рынке веб-сайтов колеблется от 500 рублей до 50 000 евро и выше. Давайте разберемся, сколько стоит сайт и почему. Простой расчет поможет убедиться в справедливой стоимости профессионально выполненного сайта и наведет заказчиков на несколько полезных жизненных выводов. Выводы навеяны опытом работы и отзывами наших клиентов. Интервалы цен приведены, по большей части, для региона «Центр».

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

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

Простой способ защиты от HTTP DDoS — включить syn-cookies и заблокировать подонков. Но что делать если атакует 5к-10к хостов да еще и с динамическими IP? Тут нам на помощь придет frontend-backend архитектура c промежуточным кэшированием! Почему с промежуточным кэшированием? А потому что в моем случае от шквала запросов от frontend'а backend умирал унося за собой систему.