Конечно, это необходимое условие, но не достаточное. Я, вроде бы, обратного и не утверждал.
Первый барьер — это вообще резюме. Ну а поскольку разборки с чужим кодом — это самый сложный процесс, то, конечно, его нужно проводить только с теми людьми, которые без пяти минут уже ваши сотрудники. Время дорого.
Что касается отказа, то я всегда считал (и продолжаю считать), что честность — лучшая политика. Если человек не подходит — не вижу смысла тратить его и свое время. Мне не трудно сказать «нет». Правду говорить легко и приятно.(с)
Порядок собеседования у меня всегда одинаков. Предварительно я рассказываю, для чего мы ищем человека (позиция, интервал оплаты, обязанности, ближайшие задачи и т.п.), т.к. если что-то из этого кандидату не подходит — лучше опять же не тратить время на дальнейшую беседу. Если у него возникают вопросы — отвечаю на них. Дальше, как я и говорил, он рассказывает что-то о своей предыдущей работе. Я задаю уточняющие вопросы в процессе. Если вероятность его найма ненулевая, то следующий этап — ревью кода или тестовое задание (его кандидат будет дома делать, так что, вероятно, будет еще одна встреча).
Как известно, при найме сотрудника нужно оценить два главных параметра: насколько он адекватен в принципе и насколько он соответствует вакансии технически. Причем первый параметр более важен, т.к. научить человека профессиональным навыкам проще, чем исправить его личностные характеристики, мешающие вам работать с ним по 8+ часов в день в одном помещении.
Поэтому первый вопрос на собеседовании: «Расскажите, пожалуйста, об одной из последних своих рабочих задач, которую Вы решали, преодолевая те или иные технические или организационные трудности?». Дальше слушаем и задаем вопросы. Если человек не может ничего рассказать о своей работе или делает это без интереса, если он винит в своих проблемах только окружающих, если начальник у него был «козлом»(тм), а клиенты — «дебилами»(тм), и т.д. и т.п. (стоп-факторов довольно много) — дальше тратить время не имеет смысла.
Ну а если кандидат кажется вполне адекватным, то дальше я предоставляю на выбор два варианта: либо он показывает мне свой код (который по его мнению характеризует его профессиональную подготовку с наилучшей стороны), либо он выполняет небольшое тестовое задание (которое я сам делаю часа за два). Как ни странно, но 90+% адекватных кандидатов (даже если они свой код показывают) с удовольствием берутся за тестовое задание, т.к. им интересно программировать.
Задание при этом я подбираю так, чтобы оно было реально похоже на работу, которую будущему сотруднику придется так или иначе делать в один из своих рабочих дней. В качестве примера: был у меня как-то длительный проект, который практически полностью состоял из работы с двумерными табличками текстовых данных (первая строка — заголовок с названиями полей, все последующие строки — данные по столбцам). Абсолютно все сотрудники так или иначе работали с данными в таком формате. Тестовым заданием было получить текстовый файл с такой табличкой на вход, загрузить в придуманную кандидатом структуру данных, отсортировать строки по значению одного из столбцов и вывести в другой текстовый файл аналогичного формата. И два бонусных (необязательных) задания — показать табличку в UI и открыть ее же в Excel.
И чего? :) Как нам это поможет отличить объект вложенного класса от enum константы?
enum E {
first,
second {
public String toString() {
return "not first";
}
};
static class Helper { }
public static final Helper helper = new Helper();
}
Я хотел сказать, что проверять, является ли объект enum константой, через obj.getClass().isEnum() — неправильно.
А правильно будет obj instanceof Enum.
Минимальные низкоуровневые тесты для проверки минимального блока кода (юнита), «оторванного от реальности». Это может быть функция, метод или маленький утилитарный класс. Можно сказать, что юнит-тесты проверяют принцип единой обязанности на уровне методов и мелких классов без зависимостей.
Признаки юнит-тестов:
Все значения в памяти
Нет обращений к инфраструктуре: нет потоков, нет файловой системы, нет БД
Сложные зависимости и инфраструктура мокаются
Интеграционные тесты
Более высокий уровень абстракции, чем юнит-тесты.
Тестирует функциональность системы (в частности класса) в связке с окружением и зависимостями. К тому же, тестируется взаимодействие составных частей (к примеру, последовательность состояний класса).
Признаки:
Тесты используют реальную инфрастуктуру: потоки, БД, файловую систему, зависимости системы
Тесты проверяют взаимодействие компонентов
Приемочные/функциональные тесты
Еще более высокий уровень абстракции, чем интеграционные тесты.
Тестируются фичи и их согласованность со спецификацией. По большей части провеярется то, что система производит нужный ответ на заданный ввод. При этом нас не интересует внутреннее состояние компонентов системы. Можно сказать, что система в приемочных тестах — черный ящик.
Признаки:
Тесты пишутся с точки зрения клиента системы
Тесты ориентированы на проверку ключевых требований, предъявляемых к конкретной фиче
Тесты проверяют соответствие ожиданий (спецификацию) и реальности
Итого: эти виды тестов не исключают друг друга. Они находятся на разных уровнях абстракции. Можно сказать, что юнит-тесты и интеграционные тесты делают проверки с точки зрения программиста, а функциональные тесты — с точки зрения клиента кода.
И да — бывают смешанные типы. К примеру, нам лень мокать зависимость от БД, но мы пишем «типа юнит-тест». В итоге получаем «интеграционный юнит-тест»(с минимальной зависимостью от БД) который в первую очередь проверяет поведение метода и в качестве стороннего эффекта — интеграцию этого поведения с БД.
Мы когда использовали Nginx на очень нагруженных серверах столкнулись лишь с одной реально неприятной проблемой — отсутствие адекватной статистики. Но проблема была решена на программном уровне — мы написали свой модуль статистики (к слову сказать, стоило это в разы меньше годовой цены на Nginx Plus), если кому интересно, прошу: github.com/FastVPSEestiOu/nginx-extended-statistics-path правда, он только под 0.76 тестировался :)
Используем mysql, по историческим причинам (ну и вообще — отличная база, просто не нужно стрелять себе в ногу и всё). У нас кстати одна из крупнейших ферм MySQL — под 500 уже наверное нод в двух ДЦ. Миграция — это выполнение в паралелль по нескольким сотням нод какой-то операции, есть фреймворк под это дело, откатить — ну так же как и на одной базе. Вы умеете на одной базе откатить альтер, например? Я — нет. Надо снова альтерить — опять в параллель пускаем операции на нодах. Всё олдскульненько.
Тут путаница. Уникальные ключи, конечно, есть. В шардированной схеме мы внешние ключи не используем по историческим причинам, но это можно сделать. Консистентность будет в пределах шарда, но это как раз нормально — именно это и требуется. Тем не менее, жить без нее не сильно сложнее, как показала практика. Отказ от внешних ключей для датабазника может показаться очень странным (я сам до этого сидел 3 года на оракле), но консистентность по внешним ключам действительно оказалась почти не нужной. Каскадные удаления — фактически единственное реальное удобство, которого нет. Но мы не удаляем данные, а олдскульно помечаем статусами. Удаляется все потом единообразная системой пуржинга. Вообще один-два раза в года я рассказываю об этом подробнее на семинаре в рамках девконфа, например.
Как мне кажется, вы неправильно повели себя с регистратором.
Я бы сделал так:
1. Отписать что была проведена проверка контента, весь найденый незаконный контент удален. Даже можно приостановить раздачу некоторых действительно спорных материалов. Будешь признателен, если они укажут на другой незаконный контент, который ты сразу-же заблокируешь. Временно блокировать, если будут присылать ссылки, сразу отписывать им об этом.
2. Объяснить ситуацию с контактными данными — домен был перекуплен у частного лица, после чего была проведена смена данных Whois через их систему управления. Однако в результате сбоя реальный Whois не поменялся. Просить у них помощи с этим вопросом. Сразу-же предоставить подтверждение реальности данных whois из интерфейса управления доменом.
3. Выразить готовность предоставить любую другую подтверждающую информацию и всячески с ними сотрудничать для решения вопроса.
После переноса к другому регистратору разблокировать весь контент.
Вы же начали качать права, потом слать одни доки, потом другие… Учитывая, что разбирается с кейсом обычно один человек — очень наивная попытка обмана.
> Мозгами надо пользоваться. При условии работающего мозга препроцессор может быть любой.
Только у SASS есть богатая экосистема расширений Compass. К примеру, расширение Compass Singularity позволяет реализовать любую модульную сетку: с произвольным количеством колонок, симметричную, несимметричную, вложенную, отзывчивую (с переменным количеством колонок), несколько разных сеток на одной странице… — и при этом весьма просто в использовании.
Какой бы светлый ни был у вас мозг, с любым другим препроцессором (и тем более без такового) вам придется изобретать велосипеды как в сабже. Разумеется, я говорю о сколько-нибудь сложной задаче.
> Сетка — это инструмент дизайнера, это скелет, по которому дизайн может быть построен лучше и, возможно, гармоничней, чем без него.
Не понял, к чему вы это. Все, что нарисует дизайнер, верстальщик должен воплотить в коде.
Неправда ваша, 6% едины, а вот 15% или меньше устанавливается на уровне регионов. В Питере, например, 10%, что практически снимает вопросы о выборе схемы «доходы» или «доходы-расходы» при сколь-нибудь значимых расходах («белой» зарплате в частности)
За своп юникс-админа кастрируют, что он не предупредил о приближении к лимиту физической памяти. От свопа мы всегда выставляем swappiness в 0.
А по поводу 50 мс — например, политика многих наших клиентов-ECN (типа bloomberg, reuters и т.п.) — отключать тех liquidity providers, задержки обработки ордера у которых превышают ms, где N как правило порядка 100. Так что 50 мс на сборку мусора — это очень-очень много для одного компонента, ведь в процессе обработки ордер пролетает через 3-4 компонента, а еще и полезное что-то надо делать… Обработка собственно ордера у нас занимает порядка 20 мс.
PS прошу прощения за обилие английских терминов, но я действительно не знаю, как они переводятся на русский…
Первый барьер — это вообще резюме. Ну а поскольку разборки с чужим кодом — это самый сложный процесс, то, конечно, его нужно проводить только с теми людьми, которые без пяти минут уже ваши сотрудники. Время дорого.
Что касается отказа, то я всегда считал (и продолжаю считать), что честность — лучшая политика. Если человек не подходит — не вижу смысла тратить его и свое время. Мне не трудно сказать «нет». Правду говорить легко и приятно.(с)
Порядок собеседования у меня всегда одинаков. Предварительно я рассказываю, для чего мы ищем человека (позиция, интервал оплаты, обязанности, ближайшие задачи и т.п.), т.к. если что-то из этого кандидату не подходит — лучше опять же не тратить время на дальнейшую беседу. Если у него возникают вопросы — отвечаю на них. Дальше, как я и говорил, он рассказывает что-то о своей предыдущей работе. Я задаю уточняющие вопросы в процессе. Если вероятность его найма ненулевая, то следующий этап — ревью кода или тестовое задание (его кандидат будет дома делать, так что, вероятно, будет еще одна встреча).
Как известно, при найме сотрудника нужно оценить два главных параметра: насколько он адекватен в принципе и насколько он соответствует вакансии технически. Причем первый параметр более важен, т.к. научить человека профессиональным навыкам проще, чем исправить его личностные характеристики, мешающие вам работать с ним по 8+ часов в день в одном помещении.
Поэтому первый вопрос на собеседовании: «Расскажите, пожалуйста, об одной из последних своих рабочих задач, которую Вы решали, преодолевая те или иные технические или организационные трудности?». Дальше слушаем и задаем вопросы. Если человек не может ничего рассказать о своей работе или делает это без интереса, если он винит в своих проблемах только окружающих, если начальник у него был «козлом»(тм), а клиенты — «дебилами»(тм), и т.д. и т.п. (стоп-факторов довольно много) — дальше тратить время не имеет смысла.
Ну а если кандидат кажется вполне адекватным, то дальше я предоставляю на выбор два варианта: либо он показывает мне свой код (который по его мнению характеризует его профессиональную подготовку с наилучшей стороны), либо он выполняет небольшое тестовое задание (которое я сам делаю часа за два). Как ни странно, но 90+% адекватных кандидатов (даже если они свой код показывают) с удовольствием берутся за тестовое задание, т.к. им интересно программировать.
Задание при этом я подбираю так, чтобы оно было реально похоже на работу, которую будущему сотруднику придется так или иначе делать в один из своих рабочих дней. В качестве примера: был у меня как-то длительный проект, который практически полностью состоял из работы с двумерными табличками текстовых данных (первая строка — заголовок с названиями полей, все последующие строки — данные по столбцам). Абсолютно все сотрудники так или иначе работали с данными в таком формате. Тестовым заданием было получить текстовый файл с такой табличкой на вход, загрузить в придуманную кандидатом структуру данных, отсортировать строки по значению одного из столбцов и вывести в другой текстовый файл аналогичного формата. И два бонусных (необязательных) задания — показать табличку в UI и открыть ее же в Excel.
E.second.getClass().getEnclosingClass().isEnum()вернет true;E.helper.getClass().getEnclosingClass().isEnum()вернет true.Я хотел сказать, что проверять, является ли объект enum константой, через
obj.getClass().isEnum()— неправильно.А правильно будет
obj instanceof Enum.E.first.getClass().isEnum()вернет true;E.second.getClass().isEnum()вернет false!В обязательном порядке смотреть бесплатный курс по нему от Google/CodeSchool — Discover DevTools.
Минимальные низкоуровневые тесты для проверки минимального блока кода (юнита), «оторванного от реальности». Это может быть функция, метод или маленький утилитарный класс. Можно сказать, что юнит-тесты проверяют принцип единой обязанности на уровне методов и мелких классов без зависимостей.
Признаки юнит-тестов:
Интеграционные тесты
Более высокий уровень абстракции, чем юнит-тесты.
Тестирует функциональность системы (в частности класса) в связке с окружением и зависимостями. К тому же, тестируется взаимодействие составных частей (к примеру, последовательность состояний класса).
Признаки:
Приемочные/функциональные тесты
Еще более высокий уровень абстракции, чем интеграционные тесты.
Тестируются фичи и их согласованность со спецификацией. По большей части провеярется то, что система производит нужный ответ на заданный ввод. При этом нас не интересует внутреннее состояние компонентов системы. Можно сказать, что система в приемочных тестах — черный ящик.
Признаки:
Итого: эти виды тестов не исключают друг друга. Они находятся на разных уровнях абстракции. Можно сказать, что юнит-тесты и интеграционные тесты делают проверки с точки зрения программиста, а функциональные тесты — с точки зрения клиента кода.
И да — бывают смешанные типы. К примеру, нам лень мокать зависимость от БД, но мы пишем «типа юнит-тест». В итоге получаем «интеграционный юнит-тест»(с минимальной зависимостью от БД) который в первую очередь проверяет поведение метода и в качестве стороннего эффекта — интеграцию этого поведения с БД.
Да, оба модуля написал он.
И платный nginx.org/en/docs/http/ngx_http_hls_module.html
И бесплатный github.com/arut/nginx-rtmp-module
Чтобы он понял вашу точку зрения, вам скорее всего потребуется вначале понять его.
Можно попробовать пролистать вот эти книжки:
Just Listen: Discover the Secret to Getting Through to Absolutely Anyone(http://www.amazon.com/Just-Listen-Discover-Getting-Absolutely/dp/0814414036)
Becoming a Technical Leader: An Organic Problem-Solving Approach (http://www.amazon.com/Becoming-Technical-Leader-Problem-Solving-Approach/dp/0932633021/ref=sr_1_1?s=books&ie=UTF8&qid=1376559982&sr=1-1&keywords=becoming+a+technical+leader)
Честно говоря — я редко встречал «тупых» людей, непонятых — постоянно.
Имхо, конечно всё.
Концепт: en.wikipedia.org/wiki/Distributed_transaction
Приложение концепта к postgresql: www.postgresql.org/docs/9.2/static/sql-commit-prepared.html
Библиотечка, которая помогает нам дёргать всё это из Java: docs.codehaus.org/display/BTM/Home
у каждой вертикальной полосочки сверху убираем обьем выполненной работы (в любых единицах, о которых изначально договорились), а новые таски в тех же единицах добавляем к низу столбика.
habrastorage.org/storage2/815/e46/209/815e46209de04571e75fa2fd0a49cf77.png
Когда график сходится — это и есть дата завершения проекта:
habrastorage.org/storage2/fab/0b1/a4c/fab0b1a4cb75baac879111e8a353525f.png
Подробнее тут: www.slideshare.net/Cartmendum/hitting-moving-target
Я бы сделал так:
1. Отписать что была проведена проверка контента, весь найденый незаконный контент удален. Даже можно приостановить раздачу некоторых действительно спорных материалов. Будешь признателен, если они укажут на другой незаконный контент, который ты сразу-же заблокируешь. Временно блокировать, если будут присылать ссылки, сразу отписывать им об этом.
2. Объяснить ситуацию с контактными данными — домен был перекуплен у частного лица, после чего была проведена смена данных Whois через их систему управления. Однако в результате сбоя реальный Whois не поменялся. Просить у них помощи с этим вопросом. Сразу-же предоставить подтверждение реальности данных whois из интерфейса управления доменом.
3. Выразить готовность предоставить любую другую подтверждающую информацию и всячески с ними сотрудничать для решения вопроса.
После переноса к другому регистратору разблокировать весь контент.
Вы же начали качать права, потом слать одни доки, потом другие… Учитывая, что разбирается с кейсом обычно один человек — очень наивная попытка обмана.
Только у SASS есть богатая экосистема расширений Compass. К примеру, расширение Compass Singularity позволяет реализовать любую модульную сетку: с произвольным количеством колонок, симметричную, несимметричную, вложенную, отзывчивую (с переменным количеством колонок), несколько разных сеток на одной странице… — и при этом весьма просто в использовании.
Какой бы светлый ни был у вас мозг, с любым другим препроцессором (и тем более без такового) вам придется изобретать велосипеды как в сабже. Разумеется, я говорю о сколько-нибудь сложной задаче.
> Сетка — это инструмент дизайнера, это скелет, по которому дизайн может быть построен лучше и, возможно, гармоничней, чем без него.
Не понял, к чему вы это. Все, что нарисует дизайнер, верстальщик должен воплотить в коде.
Есть дикий dirty hack — таки отключить System.gc(), однако, если запустить напротив процесса jmap — то он вызовет full gc внутри jvm.
А по поводу 50 мс — например, политика многих наших клиентов-ECN (типа bloomberg, reuters и т.п.) — отключать тех liquidity providers, задержки обработки ордера у которых превышают ms, где N как правило порядка 100. Так что 50 мс на сборку мусора — это очень-очень много для одного компонента, ведь в процессе обработки ордер пролетает через 3-4 компонента, а еще и полезное что-то надо делать… Обработка собственно ордера у нас занимает порядка 20 мс.
PS прошу прощения за обилие английских терминов, но я действительно не знаю, как они переводятся на русский…