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

С одной стороны, сейчас много курсов в этой области, которые проводятся на базе портала Software-Testing.Ru, УЦ Luxoft, EPAM Systems и т.д.
С другой стороны, начинающему тестировщику далеко не всегда нужны курсы. Если вы ещё не знаете, в каком направлении развиваться, какие области интересны, какие знания хочется получать – то о каких курсах идёт речь? А комплексного ВУЗовского образования для тестировщиков в СНГ пока что нет… В итоге, многие люди не могут быстро «влиться» в профессию, найти направление для развития и понять, «что и как надо изучать для быстрого старта?».

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

Итак, 7 шагов от чайника к тестировщику.

Если вы пишете документацию открытого исходного кода, то это не просто вежливые дополнение к проектам, она в определенной степени помогает вашему проекту взлететь. Хорошонаписаный README помогает, но полная документация по API делает проект более профессиональным. Даже если ваш проект с закрытым исходным кодом, документация поможет новым коллегам более быстро адаптироваться или поможет вам вспомнить как все работает в длительных проектах.

Давайте посмотрим как устроена документация в популярных JavaScript фрэймворках.

jQuery

Документация jQuery располагается по адресу docs.jquery.com и представляет из себя wiki в которой описана вся документация по API. Любая крупная область API включена в навигацию, каждая страница имеет список методов для этой области. Страница содержит примеры кода и комментарии на Disqus.
Комментарии исходного кода в основном связаны с багами или с необычным фрагментом кода, который требует пояснений.

Далее: Prototype, JSDoc и несколько специфических подходов к JavaScript документации

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

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

Каким же должен быть полный ответ на вопрос про деструкторы?

Недавно я сдавал экзамен Oracle Certified Professional Java Programmer (бывший Sun Certified), и за время подготовки прорешал огромное количество различных задачек. Отдельные задачки по джаве иногда появляются на хабре и вызывают немалый интерес, поэтому я решил поделиться накопленным и сделать небольшую подборку.

Итак, ниже представлен десяток наиболее, на мой взгляд, интересных задач по Java SE из более чем 1000, проработанных мной. Сложность варьируется от средней до ооооооочень сложной. Решение большинства задач практически не требует знания API, достаточно логики и фундаментальных основ Java.

К слову, сложность экзамена Oracle Certified Professional Java Programmer гораздо ниже чем сложность данного теста, поэтому все, кто правильно ответит хотя бы на половину этих вопросов, может смело сдавать этот экзамен без всякой подготовки.

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

ВНИМАНИЕ: во второй половине статьи — ответы и подробные пояснения по соответствующим нюансам JAVA.

Проектируя архитектуру одного проекта, остановился на паттерне MVP — подкупила возможность легко менять ui, а также простота покрытия тестами. Все примеры реализации MVP, что я нашёл в сети, были на C#. При реализации на Qt возникла пара неочевидных моментов, решение которых было успешно найдено. Собранная информация ниже.

Одной из тем в программировании, к которым интерес периодически то появляется, то пропадает, является вопрос метрик кода программного обеспечения. В крупных программных средах время от времени появляются механизмы подсчета различных метрик. Волнообразный интерес к теме так выглядит потому, что до сих пор в метриках не придумано главного — что с ними делать. То есть даже если какой-то инструмент позволяет хорошо подсчитать некоторые метрики, то что с этим делать дальше зачастую непонятно. Конечно, метрики — это и контроль качества кода (не пишем большие и сложные функции), и «производительность» (в кавычках) программистов, и скорость развития проекта. Эта статья — обзор наиболее известных метрик кода программного обеспечения.

Здравствуйте, уважаемые читатели. В качестве предисловия позвольте напомнить, что представляют собой гибридные криптосистемы и почему они получили такое широкое распространение.
Итак, гибридной криптосистемой принято называть способ передачи большого объема зашифрованных данных, при котором данные шифруются секретным ключом с применением симметричного алгоритма (например, AES или DES), а сам ключ передается зашифрованным асимметричным шифром (как, скажем, RSA). Такой способ получил широкое распространение за то, что он вбирает в себя преимущества как симметричной, так и асимметричной криптографии. Большой блок данных шифруется очень быстрым симметричным алгоритмом (и это избавляет от серьезных временных затрат), а ключ шифрования передается надежно зашифрованным с помощью асимметричного алгоритма (и это решает проблему распределения ключей, свойственную только симметричным методам). Все это достаточно широко известно, а поэтому перейдем к самому главному, а именно к вопросам реализации. И вот тут начинается много интересного.

Есть хорошая статья Питера Норвига, в которой он рассказывает как написать спеллчекер в 20 строк кода. В этой статье он показывает как поисковые системы могут исправлять ошибки в запросах. И делает это довольно элегантно. Однако, у его подхода есть два серьезных недостатка. Во-первых, исправление более трех ошибок требует больших ресурсов. А гугл, кстати, неплохо справляется и с четырьмя ошибками. Во-вторых, нет возможности проверки связного текста.



Итак, хочется исправить эти проблемы. А именно, написать корректор коротких фраз или запросов, который:

• умел бы выявлять три (и более) ошибки в запросе;
• умел бы проверять «разорванные» или «слипшиеся» фразы, например expertsexchange — experts_exchange, ma na ger — manager
• не требовал много кода для реализации
• мог бы достраиваться до исправления ошибок на других языках и других типов" ошибок

Остальное — под катом.

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

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

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

Основное различие, разумеется, в том, что Integer — это полнофункциональный объект, который занимает место в куче, а в коде вы пользуетесь ссылками на него, которые неявно преобразуются в значения:

int a = 1000; // a - число
Integer b = 1000; // b - ссылка на объект

При присваивании значения переменной типа Integer обычно выделяется память в куче под новый объект, как будто вы написали new Integer(1000) (так называемый autoboxing). Однако иногда переиспользуются старые объекты. Это иллюстрирует следующий код (JDK 1.6):

Integer a1 = 50;
Integer a2 = 50;
Integer b1 = 500;
Integer b2 = 500;
System.out.println(a1==a2);
System.out.println(b1==b2);

Результатом выполнения будет:

true
false

В версии 11g появились функции Pivot/Unpivot(которые сначала появились в MS SQL 2005), позволяющие динамически разносить вертикальные данные по столбцам как нам удобно.

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

Итак поредставим что у нас есть DAO с тремя методами — двумя для поиска сущностей и одним для сохранения сущностей. Для правильного функционирования нам нужен интерфейс и реализующий его класс (чтобы можно было добавить dynamic proxy на реализацию)

 — Здравствуй *с широко развевающейся по лицу улыбкой* дружок.
 — Ваа! *с ярким блеском в широко распахнутых глазах* Тётя Ася приехала!
 — Да, и у меня есть для тебя новая сказка *присела и взяла малыша за руки* хочешь послушать?
 — Конечно! *слегка смутился и отвёл взгляд* Мне тут дядя такие страшные истории рассказывал…
 — Ну, надеюсь моя история тебя не испугает *потрепала его по волосам* Она должна научить тебя мыслить шаблонно.
 — Эээ? *лицо перекосилось от недопонимания* Это как?
 — М… сейчас узнаешь *подмигнула и взяла на ручки* Вот когда тебе нужно вставить переменные в строку — ты как поступишь?
 — Ну… *взял карандаш и чирканул на лежащей рядом бумажке* примерно так:

var query= 'xxx'
var resultCount= 512
var message= 'По запросу <kbd>' + query + '</kbd> найдено страниц: ' + resultCount

 — Ты ничего не забыл? *победоносно подняла голову*
 — Да вроде нет… *уткнулся носом в код, ещё раз внимательно его проверяя*
 — Что, если пользователь введёт… *выдержала многозначительную паузу и добавила*

Всем привет,

Собираюсь поделиться с вами технической стороной того, как я за 16 недель сделал новый вебовый rss ридер, и чуть не сошел с ума.
Отходя от долгой предыстории, будем считать, что все началось в феврале этого года, когда мы с Дэвидом (dmiloshev, UI-дизайнер) решили сделать прототип нашего детища вдвоем.
«В одиночестве» — потому, что не было никаких скрамов, совещаний, «коллективного разума», а всю техническую часть, довелось делать самому.

Если бы меня попросили описать всю статью в одном предложении, то получилось бы:
No-SQL, mongodb, node.js, фак мой мозг, Evented I/O, очереди, выводы, git, nginx, memcached, Google Reader, Atom, TTL, PHP, ZF, jQuery, выводы.

Данная статья является приквелом статьи о группировке маркеров, ведь как известно, для того чтобы группировать что-то ненужное, надо сначала отобразить что-то ненужное;)



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

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

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

• отсутствие знаний Hildon и GTK;
• отсутствие специфичных знаний о мобильных платформах вообще;
• небольшие знания разработки настольных приложений на Qt/С++ или на любом другом языке (в этом случае придется потратить немного больше времени за чтением Qt-документации);
• немножко усидчивости и заинтересованности(хоть это и самый последний пункт, но совершенно очевидно, что он самый важный).

Таким образом я намереваюсь продемонстрировать, что создание приложений на Qt действительно не требует знаний специфики платформы в подавляющем большинстве случаев. И если приложение использует только Qt API, то оно является абсолютно переносимым между официально поддерживаемыми платформами.

Знание английского для ИТ специалиста — это одно из важнейших профессиональных качеств. Поэтому процесс изучения английского языка должен быть непрерывным. Для изучения рекомендую сайт Common Errors in English Usage, где собрано много типичных ошибок использования различных слов и выражений.

С 29 июля по 1 августа команда журнала RootUA и газеты FOSS News приглашает Вас посетить Одессу и принять участие в Первом международном Fest`е пользователей и разработчиков свободного/открытого программного обеспечения – FOSS Fest 2010. Он приурочен ко "Дню системного администратора".

В рамках Fest`а пройдёт конференция, гостей ожидают различные мероприятия, а также здоровый и приятный отдых у моря (соревнования по скалолазанию, футболу, морские заплывы, перетягивание оптики...).

Место проведения — закрытая территория учебно-тренировочной базы альпклуба «Одесса» на берегу Чёрного моря, где будет разбит палаточный лагерь.

Проблема

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

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

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

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

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

Однако простых и понятных учебников по Linux не так и много, в основном приходится собирать информацию по частям на бескрайних просторах Сети. Что, увы, иногда отбивает охоту от активных действий. Мне захотелось это исправить и помочь пользователям легко и безболезненно перейти на использование Linux, поэтому я написал руководство по Ubuntu Linux с прицелом на новичков.