Все равно, на момент написания, практически любой алгоритм переживает несколько рефакторингов

Так что ТДД - это утопия, имхо

Все равно, на момент написания, практически любой алгоритм переживает несколько рефакторингов

В теории ТДД рефакторинг можно прекрасно проводить по TDD

Так что непонятно в чем тут утопия

Если понял что твои классы работают не так как хочется - берешь пишешь новые тесты, которые фиксируют контракты и интерфейсы. Потом реализуешь код так чтобы тесты проходили.

В том, что куда проще написать алгоритм, несколько рас его отрефакторить, а после написать тесты

Алгоритм может и проще, а вот когда пишешь систему классов для бизнес логики то может и нет.

Алгоритм может и проще, а вот когда пишешь систему классов для бизнес логики то может и нет.

Ну, кому как

Впрочем меня тоже обычно заканывает писать тесты по тдд, хочется фигак и в продакшен

Но есть класс людей которые вообще против тестов, или они их очень криво реализуют. Вот такие не получают кайфа от процесса тестирования.

Но есть класс людей которые вообще против тестов, или они их очень криво реализуют. Вот такие не получают кайфа от процесса тестирования.

Ну я не против них, но кайфа от их написания я не получаю)))

Надо получать!

Когда потом после рефакторинга видишь что все сразу заработало, вместо длинной череды регрессионных багов и доделок, вот это каеф.

Почитал о сравнении Torch и TensorFlow

Торч, как я понял, требует луа, т.к. на нем написан

А тенсор можно скомпилить в либу и забиндить

Хотя большему количеству людей нравится именно торч

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

тесты это наше всё. не представляю как можно рефакторить код не имея тестов.

тесты это наше всё. не представляю как можно рефакторить код не имея тестов.

Можно. Это сложно и ресурсоемко, но можно

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

Хватает ли юнит-тестов для успешной совместной работы? Просто как же интеграционные? Ну типа как компоненты между собой взаимодействуют

ну, строго говоря, юнит-тесты нужны именно для рефакторинга, чтобы понять, что ты ничего не сломал на базовом уровне

это не отменяет полноценной команды тестировщиков

А кто JSON-API юзает вы всегда валидаторы json схемы используете?

И блин, я не могу в толк взять, что такое JSON-RPC. Да я понимаю что это удаленный вызов процедур, но если мне нужно данные передавать, то какие нафиг процедуры? И вообще когда может быть нужен удаленный вызов процедур? Ну вот реальный кейс какой-то или реальный проект есть? Я просто себе не представляю когда это бывает нужно. Все что я видел упералось в передечу данных

А кто JSON-API юзает вы всегда валидаторы json схемы используете?

Да, это крутая штука

И блин, я не могу в толк взять, что такое JSON-RPC. Да я понимаю что это удаленный вызов процедур, но если мне нужно данные передавать, то какие нафиг процедуры? И вообще когда может быть нужен удаленный вызов процедур? Ну вот реальный кейс какой-то или реальный проект есть? Я просто себе не представляю когда это бывает нужно. Все что я видел упералось в передечу данных

Ну чего? Вот тебе пример: авторизация в приложении, потом получение профиля, получение настроек, получения списка постов, размещение нового поста, редактирование поста, добавление комментария....

Любое общение с сервером

Оно тут подходит

Просто это не xml rpc, a json rpc

И блин, я не могу в толк взять, что такое JSON-RPC. Да я понимаю что это удаленный вызов процедур, но если мне нужно данные передавать, то какие нафиг процедуры? И вообще когда может быть нужен удаленный вызов процедур? Ну вот реальный кейс какой-то или реальный проект есть? Я просто себе не представляю когда это бывает нужно. Все что я видел упералось в передечу данных

Ты можешь использовать или рест или рпс

Кому как удобно

Лично мы используем именно рпс

А рест только на стороне UI

А клиенты работают по РПС

Но не json, а кастомный proto-rpc

Ты же когда передаешь какие-то данные, ты же не просто заливаешь что-то на сервер, ты должен сказать серверу, что именно ты заливаешь и зачем

Remote Procedure Call - это древнее верование наших предков о том как работает распределенная система

Короче Торч очень сильно заточен под луа(

Не думаю, что его просто и легко будет скрестить с Ди

Буду пока в сторону тенсора копать...

То есть они себе мир представляли таким - вот ты вызываешь какую то процедуру some.makeMeGood() и думаешь что она вызывается в этом же процессе/потоке и работает. А нет, на самом деле этот вызов удаленный - код завернет имя процедуры в JSON и отправит на другой сервер выполняться. Когда там все это выполнится, вернется результат, то он будет возвращен как бы этим вызовом процедуры.

И у программиста создается впечатление что он просто вызвал процедуру и она сработала.

Ну да, идея +/- такая

Только ранее оно базировалась именно на XML

А после уже сделали на JSON

Нуда, раньше было XML-RPC а щас JSON-RPC

Может ты слышал о SOAP, это и есть XML-RPC, а точнее его частный случай.

То есть они себе мир представляли таким - вот ты вызываешь какую то процедуру some.makeMeGood() и думаешь что она вызывается в этом же процессе/потоке и работает. А нет, на самом деле этот вызов удаленный - код завернет имя процедуры в JSON и отправит на другой сервер выполняться. Когда там все это выполнится, вернется результат, то он будет возвращен как бы этим вызовом процедуры.

Не понимаю ценности такого

Ну у них были свои представления о крутости архитектуры

Ну у них были свои представления о крутости архитектуры

У кого?

Не понимаю ценности такого

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

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

Я понимаю, если бы это было для получение данных, но зачем переносить логику на сервер?

Я понимаю, если бы это было для получение данных, но зачем переносить логику на сервер?

А с чего ты взял, что это не для получения данных?

Это простая коммуникация с сервером

И не важно, получение данных или какой-то расчет на сервере

Скажем так, не все можно было рассчитывать на клиенте, или просто сложно

Скажем твой клиент - это какой-то ЛОТ

То ты себе просто не можешь позволить какие-то сложные вычисления..

Я понимаю, если бы это было для получение данных, но зачем переносить логику на сервер?

Ну сервер может имплементировать логику, почему бы и нет

Тогда я не понимаб, почему всякие restapi в итоге выиграли, а rpc покрылся пылью?

Тогда я не понимаб, почему всякие restapi в итоге выиграли, а rpc покрылся пылью?

С чего ты взял?

С чего ты взял?

ИМХО

Видимо потому что сокрытие имплементации в итоге приносит проблемы

Если у тебя постоянное соединение - это только РПС

И проще в коде явно вписывать что мы делаем такой то запрос к сервису и получаем результат, нежели вызывать это все дело неявно

Тогда я не понимаб, почему всякие restapi в итоге выиграли, а rpc покрылся пылью?

Рестапи не такой уж и популярный в энтерпрайсе

И проще в коде явно вписывать что мы делаем такой то запрос к сервису и получаем результат, нежели вызывать это все дело неявно

Ты не прав, как раз рпс проще)

Просто вызвал ф-цию и все

Тот же ГрафКуЭль от Фейсбука, это РПС по своей сути, просто не json и не xml, а уже новый вид

И в самом пакете ты указываешь что ты хочешь

Да ладно вам, не покрылся rpc пылью

До сих пор всякие банки и госструктуры в мир выставляют SOAP и WSDL файлы для генерации клиентской части

Короче в rpc мы вызываем функцию и та данные возвращает? А можем просто аришку дергать без возврата данных?

Не думаю, что его просто и легко будет скрестить с Ди

У Луа мощнейшее FFI можно вызвать всё что можно скомпилировать в C. D-шные функции, экспортированные в C вызвать можно.

Короче Торч очень сильно заточен под луа(

У торчат большой плюс -- он стабилен и надёжно работает. Модели, которые ты под него найдешь скорее всего будут рабочие и с ними не будет проблем. С ТФ всё наоборот.

Я больше года не смотрел ТФ, но раньше любую модель приходилось допиливать напильником, потому что из-за частой смены АПИ ТФ они быстро превращались в тыкву.

А ещё ТФ замучаешся собирать. Торч в этом плане просто сказка была. За 5 минут всё настраивалось.

Вообще Луа очень хороший язык. Один из самых продуманных и притом очень шустрый. Только примитивный уж больно.

У Луа мощнейшее FFI можно вызвать всё что можно скомпилировать в C. D-шные функции, экспортированные в C вызвать можно.

То же справедливо для racket. Замечательный ffi, и функции из сошек собранных dmd вызываются без проблем.

Если у тебя постоянное соединение - это только РПС

Почему?

Почему?

А как иначе?

Если постоянное соединение, то слать в нем рест запросы просто глупо

Ок, спрошу у гугла

В смысле, что если у тебя уже есть свое постоянное соединение, то зачем тебе рест? Ты будешь делать уже что-то похожее на рпс

Слать данные с указанием, для чего эти данные засылаются

Так сказать, что это за запрос

Хватает ли юнит-тестов для успешной совместной работы? Просто как же интеграционные? Ну типа как компоненты между собой взаимодействуют

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

а кто-нибудь automem использует?

https://run.dlang.io/is/k2qWhm непонятно - падение на таком коде ожидаемо или нет

а кто-нибудь automem использует?

а что это?

такой случай не описан в его документации ли?

да нет там особой документации

он явно работает как хак какой-то, нет?

https://github.com/atilaneves/automem

ну не то что-бы совсем хак.

https://github.com/atilaneves/automem

Ух ты. Прикольная тема. Спасибо, гляну позже. Давно такую штуку в D хотел.

Ничосси какую дискусссию я вчера пропустил

Но больше всего доставил процесс общения, спокойно, без вые*онов. Оч круто, посоны ??