Pull to refresh
30
1

backend developer, java, go

Send message
Перемещение по рекам в течении, и сокращение пути за счет «срезания» пути через водные препятствия как раз и обеспечит «перемещение человека и полезных грузов на большие расстояния»

А назад возвращаться против течения не придется?
Будущее за такими автомобилями*, энергию для которых можно взять с собой по принципу, аналогичному «налил бензин в канистру и положил в багажник». На текущем моменте развития — это что угодно, но не электромобиль :) Он кардинально проигрывает за счет веса «топливного бака» (или «канистры») имеющего высокий удельный вес.

Чтобы какой-либо вид автомобилей стал популярным и мог бы конкурировать на свободном рынке, топливо для его энергетической установки должно удовлетворять 2 простым требованиям:
1) несложные безотказные способы хранения/накопления и перемещения
2) дешевое хранение в течении большого (очень большого) интервала времени.

* автомобиль — самоходное транспортное средство для перемещения человека и полезных грузов на большие расстояния.
Например, можно отдать 400 если входные данные не прошли валидацию парсера на предмет попыток сломать систему (иньекции и прочее). Сервис же может быть и публичным, верно?
Если исходить из предположения, что на таймаут мы повлиять не можем, то 5хх придется отрабатывать по полной программе. Но ведь ошибки бизнес-слоя прокинутые наверх, к веб-слою апи, не должны же приводить к таймаутам? Значит парадигма «отдать 200 если с транспортом все окей и внутри рассказать, что плохого случилось в результате выполнения реквеста» — это вполне себе рабочий паттерн.
А если ошибки в бизнес-слое приводят к таймаутам, то тут уж никакая балансировка не поможет, любая нода выдаст его родимого.
Неее, я немного про другое:

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

Понятно, что балансеры «из коробки» такое не умеют, но такая схема выглядит более продвинутой, нежели чем отдавать в лоб 504 или 503, и позволит заранее избежать 100% нагрузки на одну из нод бекенда.

Заголовки построенные на базе замеров выполнения реквеста не подойдут? Или там только хттп коды?

Я хочу понять мотивацию тех, кто использует подход 200 + error и тех, кто не использует 200, если error.

с развитием API (а оно произойдет, ибо энтропия бизнеса бесконечна), кодов перестанет хватать и вы утонете в документации. Подход, при котором сначала вводится понятие системы/кодов успешности/ошибок выполнения бизнес-логики, это уже как правило практически половина всей требуемой документации. Написав эту часть, вы уже сделали большую часть работы. И чем ниже уровень квалификации фронтенда или юзера на нем, тем проще будет ваша жизнь с апи построенным по первому принципу.
… хорошим тоном будет создать документацию, и отдавать её по одному из адресов(например, в корне api)
полностью поддерживаю! это best practices и очень удобный, кстати
Через боль и страдания полученные с 2004 года, пришел к паттерну, что хттп код != 200 может быть отдан только в случае некорректного формата запроса. В остальных случаях надо отдавать 200 и в теле ответа передавать код успешности выполнения бизнес логики (можно с внятной расшифровкой если требуется). Ну 401 и 403 еще исключение из этого правила. А в остальном, это работает более предсказуемо, нежели чем получить 404 на запрос свободных «слотов» в каком нить скедулере (реальный случай из практики)
Впечатляет.
Вопросы:
Минимальный размер фото в анфас с нормальным освещением и вероятностью распознавания в 90+% какой?
Производительность (кадр из видео с разрешением 720 с параметрами что в первом вопросе) «лиц в секунду» на текущем оборудовании?
какой нить классический вариант с 1пиксельной картинкой в сообщениях на популярном форуме прокатит?
Похоже они борятся с накруткой, было 12 млн 624 тысяч, рефреш и опять 12 млн 601 тыща UPD: похоже они просто инкрементят картинку на фронте, а на сервер варианты вида for (;;) уже не попадают
И объяснить хотя бы бегло в 1 абзаце, что такое сигмоида и почему выбрана она. В сети куча картинок на тему «сигмоида» vs «линейная» vs «ступенчатая» функции активации нейрона. Вот первая попавшаяся ссылка например.
Я не сомневаюсь, что этой статьей автор делает хорошее дело, но все же имеет смысл дать возможность людям понять, что такое «сигмоида» и почему она лучше для задач классификации/распознавания.
«Функция активации, имя которой -Сигмоида» это разве не оно?

На самом деле, автору надо было всего лишь указать 3 хаба в списке хабов,
— «Питон»
— «Машинное обучение»
— «Программирование»

Я думаю, что в этом случае, многие просто прошли бы мимо и не выразили бы свое возмущение. Плюс, зачем делать сознательно чрезмерно завлекательный первый абзац?

По этой же книге я и хочу пройтись пошагово, а именно по практической части — написанию кода простой нейронной сети.

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

Листал Хабр, бац! вижу «Знакомство с простейшей нейронной сетью и ее пошаговая реализация» «Машинное обучение», «Программирование»

Ура! Наконец то появилась статья не про то как подключать библиотеки на питоне, а про внутреннюю реализацию таких сетей!

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

Потираю руки, наливаю кофе, откидываюсь в кресле, тынц!

1. берем питон
2. делаем импорт либ
3. вызываем из либы сеть
4. профит!

<тут картинка с недопитым кофем и пустым вращающимся креслом >

Чем дальше, тем сильнее ощущение, что тут питонистам индульгенция выдана по теме «нейронные сети и машинное обучение: расскажите всем какие замечательные у вас есть библиотеки» :)
Есть мысль. Реализовать шифрование как ключей так и значений. RSA например (я бы и DES предусмотрел бы). Заодно и валидацию можно будет реализовать при старте. Как идея?
Обсуждение возникло из предпосылки «Возможноcть не писать бесконечные геттеры и сеттеры в Java-стиле.»

«Или я чего то не понимаю, или одно из двух», но в приведенном выше примере количество текста не меньше, нежели чем в классическом варианте getA(), setA(String A)

И как будут выглядеть проверки для сеттера и пробрасывание наверх 1...n эксепшенов?
Все же я плохо помню парадигму пропертей в дельфи, но если она точно подразумевает невозможность создания дублирующих явных геттеров и сеттеров, а также возможность указать только read или только write, плюс можно будет красиво и читабельно оформить в сигнатуре несколько эксшепшенов с разными «типами», то почему бы и нет.
Но все же хотелось бы взглянуть на то, как это могло бы выглядеть на примере. Что то мне подсказывает, что простых красивых конструкций мы не получим.
И как по вашему будет визуально выглядеть такой код? Я честно не понимаю, почему try { obj.amount = 100 } catch () {} более читабельный нежели чем try { obj.setAmount(100) } catch () {}
Второе: если я правильно помню, в дельфи остались те же самые геттеры и сеттеры. То есть мы можем реализовать изменение значения поля обьекта двумя путями, верно? Вы считаете это повышает читабельность кода?
Я не очень понимаю профита от модели property в дельфи. Например, как я сообщу внешнему миру, что полученные данные не валидны? Не молча проигнорирую, а именно «кину наверх» ошибку с внятным описанием/типом?

Information

Rating
1,719-th
Location
Москва, Москва и Московская обл., Россия
Registered
Activity