Да, этому методу меня учили в институте. Более того, я даже думал об этом методе расскзать в текущей статье, но когда закончил писать, понял, что он не дает значимого профита в сравнении с парой гантов, построенных по пессимистичным и оптимистичным срокам.
Мне что-то подсказывает, что А/B тестирование — это немного не «посмотрим продажи в январе, потом скруглим кнопку и посмотрим продажи в мае». Как минимум нужно сравнивать в одинаковых условиях. И метрики нужно брать вменяемые. И выборки побольше.
Я, конечно, не свежеиспеченный выпускник, но все же с удовольствием послушаю про промышленные языки Smalltalk и Eiffel и их активное применение в «промышленном программировании».
Если вам очень нужно (в 2016 году очень нужно?) объявить глобальную переменную — просто объявите ее в заголовочном файле как extern. После этого в реализации объявляете эту переменную и работаете с ней сколько угодно.
На это очень тяжело отвечать серьезно, потому что в plain old C именно так и делали, и выглядело это вот так:
https://www.openssl.org/docs/manmaster/crypto/ERR_error_string.html
Конечно, подход не самый красивый, но он связан в первую очередь с ограниченим языка. Вы в PHP с объектной моделью можете возвращать некий ValidationResult, который содержит всю необходимую информацию.
Штатная исключительная ситуация — это ситуация, которую программа способна распознать и продолжить корректную работу после ее возникновения. К таковым относятся, к примеру, ошибка валидации, ошибка аутентификации, и прочие ошибки, которые программист способен предусмотреть и обработать без потери целостности и консистентности состояния системы.
Нештатная исключительная ситуация — это сиутация, при возникновении которой дальнейшая работа программы невозможна ввиду недетерминированности ее внутреннего состояния. К примеру, к таковым относятся удаление файла БД в приложении.
Где-то между ними болтается класс ситуаций, которые невозможно распознать напрямую, но в то же время их возможно изолировать без нарушения внутреннего состояния приложения. Например, если вы внезапно получили через web api вмеcто json какой-то странный html с 200 кодом возврата. Понятно, что сделать с ним вы ничего не можете, но совершенно необязательно это разрушает ваше приложение.
Я утверждаю, что обрабатывать штатные исключительные ситуации необходимо с помощью кодов возврата. Это может быть что угодно, принятое для вашего языка — от getlasterror до монады error. Нештатные исключительные ситуации должны выбрасывать терминальные исключения и завершать работу приложения (с 500 ошибкой для веба). То что болтается посередине обрабатывается исходя из возможности восстановить работоспособность приложения.
То есть согласно моей позиции исключения могут быть только терминальными, но допустимо использовать их обработчики, которые, условно говоря, перед завершением приложения покажут пользователю красивую картинку, что что-то пошло не так и мы это чиним.
Я, конечно, не могу утверждать, что это единственно возможный подход, однако мой опыт подсказывает мне, что он самый оправданный.
Результаты опроса следует читать так: 96% людей считают, что могут реализовать binary search. Впрочем, написанный ими код наверное будет иногда работать https://habrahabr.ru/post/203398/
Апологеты MVP с вами радикально несогласны. Впрочем, я тоже, так как вначале должен быть proof of concept, а для него допустимо использовать любые средства, вплоть до вероятностных алгоритмов.
В самом Трекере есть возможность построения диаграммы Ганта, я в основном строю ее по проектам.
Опытный менеджер всегда имеет в голове константу, на которую нужно умножать сроки.
Да, этому методу меня учили в институте. Более того, я даже думал об этом методе расскзать в текущей статье, но когда закончил писать, понял, что он не дает значимого профита в сравнении с парой гантов, построенных по пессимистичным и оптимистичным срокам.
Если вам очень нужно (в 2016 году очень нужно?) объявить глобальную переменную — просто объявите ее в заголовочном файле как extern. После этого в реализации объявляете эту переменную и работаете с ней сколько угодно.
Пора сделать второй шаг. Открыть любую статью по парсингу и прочитать про BNF и EBNF, LL и LR, SLR и LALR, PEG и Regex и познать дзен.
Пользователь облажался в одной букве, а вы в ответ АЛЯРМ ААА ПАНИКА НЕПРАВИЛЬНЫЙ ПАРОЛЬ ВСЕ В ИСКЛЮЧЕНИЕ.
Ну несерьезно это.
https://www.openssl.org/docs/manmaster/crypto/ERR_error_string.html
Конечно, подход не самый красивый, но он связан в первую очередь с ограниченим языка. Вы в PHP с объектной моделью можете возвращать некий ValidationResult, который содержит всю необходимую информацию.
Штатная исключительная ситуация — это ситуация, которую программа способна распознать и продолжить корректную работу после ее возникновения. К таковым относятся, к примеру, ошибка валидации, ошибка аутентификации, и прочие ошибки, которые программист способен предусмотреть и обработать без потери целостности и консистентности состояния системы.
Нештатная исключительная ситуация — это сиутация, при возникновении которой дальнейшая работа программы невозможна ввиду недетерминированности ее внутреннего состояния. К примеру, к таковым относятся удаление файла БД в приложении.
Где-то между ними болтается класс ситуаций, которые невозможно распознать напрямую, но в то же время их возможно изолировать без нарушения внутреннего состояния приложения. Например, если вы внезапно получили через web api вмеcто json какой-то странный html с 200 кодом возврата. Понятно, что сделать с ним вы ничего не можете, но совершенно необязательно это разрушает ваше приложение.
Я утверждаю, что обрабатывать штатные исключительные ситуации необходимо с помощью кодов возврата. Это может быть что угодно, принятое для вашего языка — от getlasterror до монады error. Нештатные исключительные ситуации должны выбрасывать терминальные исключения и завершать работу приложения (с 500 ошибкой для веба). То что болтается посередине обрабатывается исходя из возможности восстановить работоспособность приложения.
То есть согласно моей позиции исключения могут быть только терминальными, но допустимо использовать их обработчики, которые, условно говоря, перед завершением приложения покажут пользователю красивую картинку, что что-то пошло не так и мы это чиним.
Я, конечно, не могу утверждать, что это единственно возможный подход, однако мой опыт подсказывает мне, что он самый оправданный.
Думаю, пора выпускать дистрибутивы БД с надписью «без алгоритмов».