Дистанционное обучение в IT

Где набраться новых знаний в такой распространенной области, как IT?
Особенно, если тратить деньги не очень хочется...

Советую обратить внимание на огромный подарок от "Computer Sience" клубов. Почитать о нем можно здесь.

Что он включает?

Computer Science Center

Это наши новые друзья, совместный проект Школы анализа данных Яндекса, CS клуба, Академии современного программирования и ФМЛ №239. Занятия начались осенью 2011.
Это первые, вступительные курсы.

2011

Основы баз данных, Илья Тетерин
Основы математики, Александр Храбров
Основы C++, Евгений Линский
Основы Java, Георгий Корнеев
Алгоритмы и структуры данных, Александр Куликов
Обзорный курс по анализу данных, Юлия Киселёва
Вычислимость и логика, Дмитрий Ицыксон

Питерский Computer-Science клуб

Это наши старые друзья. Читайте прошлогодний пост об архиве других лет.

осень 2011

Компьютерная графика, В. А. Галинский
Модели веб-графов и их приложения А. М. Райгородский
Введение в комбинаторику слов, А. Э. Фрид
Computer Science семинар (осень 2011)

2010-2011

Линейное программирование, М. А. Бабенко
Квантовые алгоритмы: возможности и ограничения М. Н. Вялый
Параметризованные алгоритмы, Ф. Фомин
Системы типизации лямбда-исчисления, Д. Н. Москвин
Computer Science семинар (весна 2011)
Компьютерное зрение и библиотека OpenCV, В. Л. Ерухимов
Анализ поисковых запросов, П. Браславский
Синхронизируемые автоматы, М. В. Волков
Program Analysis for Security, B. Livshits
Проблема изоморфизма графов, И. Н. Пономаренко
Онтология и представление знаний, Б. Ю. Конев
Семантическая классификация изображений, А. Конушин
Функциональное программирование, Е. Р. Кирпичёв
Теория сложности доказательств, Э. А. Гирш
Computer Science семинар (осень 2010)

И многое-многое другое. Выбирайте интересные для вас знания и изучайте, изучайте, изучайте...

Простые, понятные автотесты. Где почитать о том, как их создать?

Хотите писать простые и понятные автотесты, но не знаете, с чего начать?

Разумеется, об этом уже говорилось! Надо только ссылки знать :)

Если вы хотите пишать на PHP, то вам прямая дорога на Хабр.
О чем там вообще говорится? Есть такой проект, Codeception.

С ним тесты для ваших веб-приложений могут выглядеть так:

<?php
$I = new TestGuy($scenario);
$I->wantTo('create new blog post');
$I->amOnPage('/blog/posts');
$I->click('Create new post');
$I->fillField('Title','Codeception, a new way of testing!');
$I->fillField('Text','Codeception is new PHP full-stack testing framework.');
$I->click('Send');
$I->see('Congratulations, your post is successfully created!');

Таким образом, при минимальном знании английского языка, которому учат в школе, вы можете составлять тесты вида "Я заполняю... Я вижу...". А уже если вас, ко всему прочему, привлекает именно PHP, то эта статья - просто манна небесная! Попробуйте, возможно, автоматизация - это не так страшно :)

Codeception работает на трех китах:
— как тестовая среда используется PHPUnit.
— для приемочных тестов — Mink. За него огромная благодарность Константину Кудряшову everzet.
— и конечно же, Symfony Components. Они используются практически для всего. Особо стоит отметить BrowserKit, который используется для функциональных тестов.

Ну а если вы не знаете английского и хотите работать на С#, и при этом, опять же, хотите автоматизировать и иметь читабельные тесты, заходите на Автоконфетку. Я покажу, как написать тесты, которые смогут понять даже не-программисты

Testing-by-contract VS defensive testing

Имеется у нас приложение. Для регистрации надо указать возраст.

До 12 лет - отказать в регистрации.
От 12 до 18 лет - дать доступ, но с ограничениями.
Больше 18 лет - полная регистрая, полный доступ к сайту.

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

Классы эквивалентности гласят, что нам нет смысла проверять все значения от 0 до 100 (бывают же долгожители). Мы можем взять по одному значению из каждого множества. Возьмем 5, 16 и 22. Все? Как насчет значений "10000", "-88", "%;№№"/"? Будем проверять?

Конечно же - "ДА!". Скажут многие. И будут по-своему правы.

Но знают ли они, что применяют именно "defensive testing"? Что есть и другой подход?

Далее идет вольный перевод Lee Copeland – “A Practitioner's Guide to Software Test Design”

Существует такой подход - design-by-contract. Под контрактом мы понимаем некие соглашения между частями, описывающими, что мы будем и не будем делать. В этом подходе методы описываются с помощью пред-условий и пост-условий. Пост-условие (post-condition) - это то, что модуль обещает сделать (открыть файл, сохранить значения, одобрить или отклонить регистрацию). Пред-условия (pre-condition) описывают требования к модулю, при которых он переходит в состояние, описываемое пост-условиями.

Например: функция, открывающая файл.
Post-condition: открыть файл
Pre-conditions: открываемый файл должен существовать, содержать нужное нам имя, быть "openable"...

Testing-by-contract основывается на философии design-by-contract. При использовании данного подхода мы пишем только те тест-кейсы, которые удовлетворяют нашим pre-condition. То есть на открытие файл мы НЕ пишем тест-кейс аля "файл не существует". Мы не создаем негативные кейсы, только позитивные.

У многих тестировщиков этот подход вызывает протест. Да еще какой! Как же так, а как же быть с некорректными условиями, а? Вы что?! Это очень важно!!

Да, важно! И для этого существует другой подход - defensive testing. Мы проверяем, что если условия удовлетворяют нашим pre-condition, то выполняет корретное пост-условие. Если же условия противоречат нашим pre-condition, то выдается корректное же сообщение об ошибке.

Таким образом, прежде чем ответить на поставленный вопрос: "Как насчет значений "10000", "-88", "%;№№"/"? Будем проверять?", вначале надо уточнить, а какой подход используется:

Если testing-by-contract - то ответ "Нет".
Если defensive testing - то ответ "Да".

А какой подход используете вы? :)
У меня первый подход вызывает протест. Как же так, забить на то, что вместо корректного сообщения об ошибке пользователь видит... Страшные вещи, порою... Тем более что пользователи довольно часто забивают неверные значения = им надо показывать корректные сообщения об ошибке. Иначе зачем им вообще нужна такая система, которая разваливается при каждом чихе? "Шаг влево, шаг вправо - расстрел" (с)

Нет, мы лучше обработаем возможные ошибки нормально - "Уважаемый юзер! Вам ну никак не может быть минус 93 года. Перепроверьте, пожалуйста, введенные вами данные и научитесь лгать поправдоподобнее. Спасибо за внимание, искренне ваш, Админ"

SQL - join it! Запросы к БД

Итак, диаграмму Базы Данных мы создали.

Теперь надо к ней как-то обратиться. А прежде чем обращаться к БД, надо ее заполнить. Мы создали таблицы, но не заполнили их.

Исправляем недочет! Раскрываем свою базу данных - Tables - dbo.Author - правый щелчок - редактировать первые 200 значений.

Заполняем Фамилию и Имя, колонка id генерируется сама (так как мы все такие колонки сделали автоинкрементными)

По аналогии заполняем остальные таблицы - Book, BookAuthorship, Author.

Потом создаем запрос. File - New Query. Или нажимаем на кнопку в вытащенном меню

Открывается пустая страница.
Что мы хотим? Хотим вытащить все колонки из таблицы "Book".

Ок, пишем:

Создание схемы Базы Данных

Человек запоминает 10% услышанного, 20% увиденного и 70% того, что он сделал сам. А чтобы закрепить успех, необходимо научить других тому, что знаешь сам.
Правда, до учителей многим (мне, в частности) далеко, но можно хотя бы записать то, что узнал, для таких же новичков - пошагово. При написании текста внезапно понимаешь, что не все так просто и ты за сутки половину забыл :) Но я попробую закрепить новые знания.
Итак, основная задача - в автоматическом тесте при подготовке данных изменить базу, а не ползать через GUI.
Чтобы изменить базу, надо вначале понять, как нам к ней обращаться. Чтобы к ней обращаться, надо знать, как она строится.
Разберемся на примере базы книг. Мы хотим создать диаграмму Базу Данных имеющихся в наличии книг. У каждой книги есть какой-то жанр и какой-то автор.
Причем у каждой книги должен быть строго один жанр и один или несколько авторов.

Где будет создавать? В специальном приложении.

Устанавливаем и запускаем Microsoft SQL Management Studio.
Видим окно "Connect to Server", где мы можем выбрать тип и имя сервера, а также аутентификацию - выбираем Windows Authentication - Connect.
Слева появилось меню - Object Explorer.
Разворачиваем наш сервер - видим следующий список

Databases (правый клик) - New Database
Создаем базу книг -  Books.
Разворачиваем нашу базу.
Database Diagram - New Database Diagram

Когда мы рисуем диаграмму и добавляем туда таблицы, они появляются в разделе таблиц - повторяться нам не придется.
Когда мы создаем новую диаграмму, открывается пустое окно. Щелкаем правой кнопкой - New Table.
Начнем с книг. Называем таблицу Book (называть таблицы принято в единственном числе).
Заполняем ее, как на рисунке, только пока - без "ключика" слева от поля "id".

Что мы сделали? Мы сделали таблицу книг, сказав, что колонками у нее будут - id, название и описание. Имена колонкам дали.
Data Type - тип данных, id - число, поэтому int. С другой стороны, это не просто число. Id должно увеличиваться, желательно само. Это называется автоинкрементное поле - задаем начальное значение и инкремент, шаг, на который поле будет увеличиваться с каждой новой записью в базе.

Чтобы сделать id автоинкрементным, открываем свойства этой колонки.
View - Properties Window.
В свойствах нас интересует Identity Specification.
Разворачиваем пункт, говорим, что да - поле "самовозрастающее", ставим "Yes".
Указываем инкремент и Seed (начальное значение)

Название и описание - строки. Указываем им тип "nvarchar(50)" и ручками меняем число "50" на любое другое количество символов.
Allow Nulls - в этой колонке мы указываем, будет ли поле обязательным для заполнения. То есть если галка стоит - "вводить null разрешено", а "вводить null" = "не вводить ничего". Id и имя - обязательные поля, они есть у каждой книги. Описание можно оставить необязательным - ставим там галку.

Книги создали. Правый клик - New Table - Genre.

Что должно быть у жанра? Id и имя. Оба поля обязательны.
По аналогии создаем таблицу авторов:

Ок, таблицы есть. Теперь надо настроить связи между ними.
Как настраиваются связи? С помощью ключей. Почитать о них можно в вики, в строке "Ключи" приведенной таблички.
Нас интересуют:
1. PK - primary key, первичный ключ.
Он накладывается на всю таблицу, но мы можем выбрать одну или несколько колонок.
Выбираем одну колонку - ключ говорит о том, что каждое значение в ячейках этой колонки уникальное.
Выбираем несколько колонок - ключ говорит о том, что комбинации строк по колонкам уникальны.
2. FK - foreign key, внешний ключ.
Нужен для связки двух таблиц в разных соотношениях (1:1, 1:N, N:N)
Этот ключ указываем в "дочерней" таблице, то есть в той, которая ссылается.
Обозначим наши ключи. Для этого нам помогут следующие действия:

Set Primare key - назначить PK
Relationships - назначить FK

Во всех трех таблицах назначаем колонку "Id" первичным ключом - Set Primare key.
Слева от строки появятся ключи, как на картинках выше.

Разберемся со связями.
У одной книги может быть только один жанр.
Одному жанру может соответстветствовать много книг.
В таблице "Book" добавляем еще одну колонку - "genreId", значение int, поле обязательно для заполнения. Так как книга без жанра быть не может.
В таблице "Book" в колонке "genreId" открываем Relationships. В открывшемся окне при необходимости меняем название. Делается это в свойстве Identity - Name

Название заполняем по шаблону
FK_Таблица, которая ссылается_Таблица, на которую ссылаемся

Потом в основных свойствах выделяем "Спецификация таблиц и колонок", нажимаем на многоточие

Открылось окно, в котором слева мы указываем таблицу, на которую мы ссылаемся и ее первичный ключ

Мы говорим, что в колонку "genreId" таблицы "Book" передается значение "id" таблицы "Genre"
Сохраняем - видим связь между таблицами

Знак ключа говорит о том, что от этой таблицы мы берем одно значение, которое соответствует многим значениям другой таблицы, так как с ее стороны мы видим "бесконечность".
Это реализация 1:N или 1:1 (в этом случае внешний вид связи будет выглядеть как "ключик - ключик").
Чтобы реализовать связь N:N, нам понадобится ассоциативная таблица. Мы не можем сделать "бесконечность" к "бесконечности" напрямую, поэтому для такой связи таблиц мы создаем промежуточную таблицу, в которую обе исходные входят по указанному выше принципу "один ко многим".
New Table - BookAuthorship.

Комбинация идентификаторов "книга + автор" должна быть уникальными (ставим РК) и обязательными для заполнения
Тип данных bit возвращает значение "истина" при вводе 1 и "ложь" при вводе 0.
Relationships - создаем два внешних ключа. Которые сопоставляют:
"bookId" в таблице "BookAuthorship" с "id" в таблице "Book"
"аutorId" в таблице "BookAuthorship" с "id" в таблице "Autor"
Диаграмма готова!

Ключевые переговоры - что и как говорить, когда ставки высоки?

Ссылка на OZON.

Тоже хочу похвалить книжку издательства "Манн, Иванов и Фербер".

Она, конечно, напрямую к тестированию отношения не имеет, но зато имеет отношение ко всему остальному :)

Под переговорами, в которых "ставки высоки" понимаются любые сложные переговоры. Как донести информацию и не переругаться с родными, соседями, коллегами?

Как часто на работе вы общаетесь с начальством или подчиненными? Всегда ли вас устраивают эти диалоги? Всегда ли вы сами ведете себя корректно, не повышая голос, не переходя на спор?

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

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

Надеюсь, у меня получится стать немного лучше :)

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

PS - Добавила книгу в общий список прочитанных мною книг.

Зачем нам тренинги?

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

Далеко не всех тянет изучать что-то новое. Хотя просто стимула нет. Мотивации. Глаз горящих. Ну а правда - зачем? Тем более, если начальство не поддерживает (читай, нашел, сделал - оказалось никому не нужно, так, отмахнулись). И так бывает... По всякому бывает.

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

Однако человек, привыкший к своему рабочему месту, на котором не надо напрягаться, врядли найдет себе коллектив "по душе". Там ведь работать надо, а уже лень. Или даже не лень, но не возьмут. Кому он нужен. твой скудный опыт?

Но даже если в команде все хорошо. Надо ли оно? На тренинги ходить, на конференции ездить? Все же хорошо! Для своих проблем знаний хватает!

Как однажды заметил Абрахам Маслоу: "Тому, у кого из инструментов в наличии только молоток, любая проблема кажется гвоздем" (с)

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

И ничего. Раньше думать надо было.

Всегда полезно взглянуть на точку зрения под разными углами. Понимать, что не все вокруг - гвозди. Нет, конечно, Eclipse и Java меня все равно не устраивают, мне C# подавай, но это уже так - молотки все, просто с разными рукоятками. Кому какая удобнее.

А вот  изучить проверку безопасности, JMeter, JBroFuzz и тд - это да. Это нужно, важно и полезно. Для себя, любимых :)