Контакты

Достижения

Все достижения (22)

Наибольший вклад в теги

Все теги (254)

Лучшие ответы пользователя

Все ответы (166)
  • Чем отличается junior от middle? а Senior?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Вот как это выглядит с т.з. работодателя

    Джун
    - собеседование
    изъясняется исключительно на сленге (большую часть которого не может внятно объяснить), готов в одиночку за неделю написать новую ОС, или две - за полторы, если только для этого не придется учить ассемблер, несмотря на юный возраст уже обладатель прав на обе версии и один бэкап личного сайта с фотографией кошки в розовой рамке и знает, что синглтон - это абсолютное зло, хотя и не может написать его без ошибок.
    - испытательный срок
    долго мудохается с настройками рабочего места, которые регулярно слетают под тяжестью многотысячных плагинов, шелов и скринсейверов, донимает админов, находит две (орфографические) ошибки в документации проекта и один быстрый альтернативный способ сделать форк из SVN, после которого проект, к сожалению, не билдится не только у него, но и у всей команды. Берется все немедленно исправить с помощью другого чудотворного плагина, (неожиданный баг в котором приходится фиксить двум миддлам), после чего насильственно лишается рута, плагинов и шелов и начинает изучать проект под чутким контролем матерящихся миддлов.
    - работа
    научился билдить проект, писать тесты и коммитить, не роняя этим билд, понял смысл многих сленговых выражений, подружился с миддлами и админами, не путается в названиях ключевых технологий, радикально сократил число плагинов, удалил сайт с кошкой, работает.

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

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

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Объяснить суть полиморфизма "на пальцах" довольно просто. Представьте себе класс Телефон. Его спроектировал некто в далеких 80-х, и определил в нем метод набратьНомер(). А потом другой программист в 90-х отнаследовал от него класс МобильныйТелефон и перекрыл метод набратьНомер(), т.к. грубо говоря, в новом устройстве набор производится уже не импульсно, а тонально. А потом третий программист отнаследовал от него класс Смартфон. При этом он не стал трогать метод набратьНомер(), а просто добавил методы для нового функционала, типа определитьПоложениеПоGPS() и т.д.

    Теперь представьте себе пользователя. Он родом из 80-х и понятия не имеет о тональном наборе и GPS... но если ему в руки дать любое из этих устройств, он сможет набрать номер и сделать звонок. Почему? Потому, что он умеет использовать метод набратьНомер(), и большего ему знать не нужно.

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

    Применительно к ООП, пользователь - это переменная, содержащая ссылку на экземпляр класса. Ее тип (как она была объявлена) - это "набор знаний" о возможностях этого экземпляра. И т.к. Смартфон в своей основе является Телефон-ом, мы вполне можем дать его в руки гипотетическому пользователю из 80-х:
    Телефон устройство = new Смартфон();
    в результате чего он сможет сделать звонок:
    устройство.набратьНомер("03");
    А вот определить свое местоположение он не сможет, пока не узнает о существовании соотв. метода:
    Смартфон усовершенствованноеУстройство = (Смартфон)устройство;

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

    P.S. Кстати, в этом примере мы затронули не только полиморфизм, но и наследование, и инкапсуляцию (пользователя "снаружи" совершенно не интересует, как именно производится набор номера - тонально, импульсно или еще как-то иначе)... так сказать, все три кита ООП в одном флаконе. И только так вообще имеет смысл рассматривать эти принципы, т.к. они по сути неотделимы друг от друга, как Отец, Сын и Святой Дух в Христианстве или же длина, ширина и высота в трехмерном пространстве :) Если это понять, ООП становится совершенно простой и естественной парадигмой программирования.
    Ответ написан
  • Что такое end-to-end тестирование?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

    Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

    И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

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

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Потому, что "высоко-/низко-уровневый" это просто условная и достаточно относительная классификация языков по одному конкретному качеству - по уровню абстракции, предоставляемой языком его пользователю. А когда всплывает слово "абстракция", обязательно нужно задуматься над тем, что от чего абстрагируется. В данном случае речь идет об абстрагировании конструкций языка от среды выполнения программы, написаной на этом языке. Например, во всех этих ЯВУ есть такие абстракци, как именованная переменная, тип данных, конструкции управления потоком выполнения или вызов функций системы/стандартных библиотек и т.д. Мы просто пишем int а = 3; или while(flag == true)..., а обо всем остальном заботится язык. Для сравнения, в ассемблере (низкий уровень) нам приходится иметь дело с конкретными регистрами, битами, адресами и jump-ами, и никакой среды, которая пришла бы нам на помощь, там тоже нет. В этом смысле уровень абстракции того же С намного выше.

    Классификация эта (как и любая другая) - условная, т.к. если по этому признаку сравнить, например, те же Яву или Шарп с теми же C++ или Паскаль, то можно бы было сказать, что уровень абстракции первых "несколько выше" - между программой на первых языках и "средой" есть еще промежуточный уровень (байткод/IL), а программы на вторых компилируются прямо в инструкции конкретного процессора. Только смысла в таком утверждении уже не так много, и для указания на эти качества языков проще и полезнее классифицировать их как "компилируемые в инструкции виртуальной машины" и "компилируемые в инстрикции процессора".

    И, наконец, сортировка массива - это уже совсем из другой оперы. К языку тут (если вообще!) относится только абстракция "массив". В большинстве языков есть такое понятие, как стандартная библиотека (JDK, stl, те же модули в пыхе и т.д.). Функции вроде сортировки массива, предоставляются не языком, а именно этой библиотекой (как правило, написанной на этом же языке и/или на более низкоуровневых). А, собственно, языком называется очень-очень маленький набор универсальных семантически однозначных конструкций, типа операторов сравнения, циклов или вызовов функций. Фактически, любой современный язык можно "выучить" за день... остаток жизни уйдет на то, чтоб научиться правильно пользоваться им и его библиотеками для написания нужных программ ))
    Ответ написан
  • Wireshark не видит сетевой интерфейс в Ubuntu 14.04, что делать?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Сначала
    sudo dpkg-reconfigure wireshark-common
    Там согласиться с тем, что не только root должен иметь возможность снифить пакеты.

    Потом добавить себя к группе wireshark
    sudo adduser $USER wireshark
    (после чего не забыть перелогиниться!)

    Профит.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (3)