Pull to refresh
9
0
Виктор Брыксин @bobermaniac

User

Send message
Мне что-то подсказывает, что А/B тестирование — это немного не «посмотрим продажи в январе, потом скруглим кнопку и посмотрим продажи в мае». Как минимум нужно сравнивать в одинаковых условиях. И метрики нужно брать вменяемые. И выборки побольше.
Я, конечно, не свежеиспеченный выпускник, но все же с удовольствием послушаю про промышленные языки Smalltalk и Eiffel и их активное применение в «промышленном программировании».
Жутковато.

Если вам очень нужно (в 2016 году очень нужно?) объявить глобальную переменную — просто объявите ее в заголовочном файле как extern. После этого в реализации объявляете эту переменную и работаете с ней сколько угодно.
Хотите я вам скину ссылку на видео с вечным двигателем?
А векторная сеть-то где? Пока я вижу парсер прошлого века, только многократно ухудшенный.
Мне кажется, вы написали какое-то подмножество LL(0)-лексера. Глючного, не поддерживающего рекурсию, но лексера.

Пора сделать второй шаг. Открыть любую статью по парсингу и прочитать про BNF и EBNF, LL и LR, SLR и LALR, PEG и Regex и познать дзен.
Ну я, если честно, не очень понимаю, почему при вводе неверных креденшалов у вас «дальнейшее выполнение программы невозможно».

Пользователь облажался в одной букве, а вы в ответ АЛЯРМ ААА ПАНИКА НЕПРАВИЛЬНЫЙ ПАРОЛЬ ВСЕ В ИСКЛЮЧЕНИЕ.

Ну несерьезно это.
Я и не утверждаю, что это неудобно. Я утверждаю, что это некорректно.
На это очень тяжело отвечать серьезно, потому что в plain old C именно так и делали, и выглядело это вот так:
https://www.openssl.org/docs/manmaster/crypto/ERR_error_string.html

Конечно, подход не самый красивый, но он связан в первую очередь с ограниченим языка. Вы в PHP с объектной моделью можете возвращать некий ValidationResult, который содержит всю необходимую информацию.
Ok, let's talk 'bout philosophy.

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

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

Где-то между ними болтается класс ситуаций, которые невозможно распознать напрямую, но в то же время их возможно изолировать без нарушения внутреннего состояния приложения. Например, если вы внезапно получили через web api вмеcто json какой-то странный html с 200 кодом возврата. Понятно, что сделать с ним вы ничего не можете, но совершенно необязательно это разрушает ваше приложение.

Я утверждаю, что обрабатывать штатные исключительные ситуации необходимо с помощью кодов возврата. Это может быть что угодно, принятое для вашего языка — от getlasterror до монады error. Нештатные исключительные ситуации должны выбрасывать терминальные исключения и завершать работу приложения (с 500 ошибкой для веба). То что болтается посередине обрабатывается исходя из возможности восстановить работоспособность приложения.

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

Я, конечно, не могу утверждать, что это единственно возможный подход, однако мой опыт подсказывает мне, что он самый оправданный.
Данные не проходят валидацию — это не исключительная ситуация, поэтому такой код семантически некорректен.
Я не очень понял насчет RVO. Есть же rvalue reference и move semantics?
Результаты опроса следует читать так: 96% людей считают, что могут реализовать binary search. Впрочем, написанный ими код наверное будет иногда работать https://habrahabr.ru/post/203398/
Апологеты MVP с вами радикально несогласны. Впрочем, я тоже, так как вначале должен быть proof of concept, а для него допустимо использовать любые средства, вплоть до вероятностных алгоритмов.
А в чем фетиш писать все на Свифте? ObjC никуда не делся и в силу его природы работать с ним для парсинга JSON-подобных структур куда проще.
Вообще говоря, было бы очень неплохо. Не в подробностях, но хотя бы в общих чертах.
В той БД, которую вы используете каждый день — какие-то другие вещи, а не алгоритмы?

Думаю, пора выпускать дистрибутивы БД с надписью «без алгоритмов».
Простое решение — собрать мапредьюс из грязи и веток и залить процессорами. Развернуть все абстракции, вытащив наружу только то, что реально нужно — решение сложное.
А особенности используемой БД разве не выражаются в тех алгоритмах, которые там используются?
А потом получается, что простейшая задача решается с помощью трех десятков слабо совместимых между собой библиотек в соответствии с принципом чайника, из-за чего умудряются тормозить даже на ферме из 20 блейдов не самых чахлых конфигураций. Зато с реактом, редисом и монетизацией через микротранзакции, все как у больших мальчиков.

До сих пор ситуация в мире разработки напоминала мне *вырезано ибо политика* — любую мало-мальски сложную проблему пытались залить процессорными мощностями, памятью и каналами данных. Они росли и было круто. Теперь они расти перестали и снова пора начинать думать, отсюда все больше требований к математике среди девелоперов.

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity