тайпоф проверяет же только стандартные типы джаваскрипта

А других и не будет, если ты не тянешь тс в проект

Ну получается что бы проверить объект правильный, который ожидается приходит или нет, надо будет свойства проверять и перебирать?

тоже самое, что и делается внутри ТС, разве нет?

Ну, до ТСа приходилось так и не скажу, что не справлялся, опять же, для меня ТС просто решает проблему написания проверок и сразу демонстрацию мне ошибок, но не более

Я просто хочу выбрать какая отрасль лучше

Ну только в реакте в propsTypes, но это тоже не так давно было

А когда будешь выбирать, какая жена лучше, тоже будешь интересоваться общественным мнением?

Даааа

ну, я помню у меня на собесе была задача написать функцию, с каррированием и проверкой типой, приведенмем типов и всякой другой чушью, то делал внутри проверки типов, что призодит и что выводить, проблема только, что в маленькой по функционалу функции было овер 15 строчек кода)

Ну получается что бы проверить объект правильный, который ожидается приходит или нет, надо будет свойства проверять и перебирать?

И как, справился? Я про каррирование только читал, не применял никогда

Юнит-тесты, ещё раз говорю. Грамотные юнит-тесты

но опыт хороший, не лишний точный, потом подобное увидел у S0er'а, тоже немного подчеркнул нового

Читай библию QA и Куликова https://github.com/VladislavEremeev/QA_bible

https://docs.google.com/document/d/1N-SxSRbe5eaV3z4BEknNVB1G7EKgtfdgVmTyy-q95fY/edit?usp=sharing

И как, справился? Я про каррирование только читал, не применял никогда

тогда выбирай хорошую жену

Например, заодно можно добавить много дополнительных проверок типа диапазон, ... function foo(a, b) { precondiion(a, 'numeric'); precondition(b, 'numeric', make_range(2,5)); }

Как-то у чуваков тесты и tdd не в почете видать )

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

Блин, ну если, условно, у тебя приложение может лечь от кривого респонса от сервера, то явно и приложение написано криво, и правильнее обработчики обложить тестами и сделать все, чтобы оно не легло, чем тащить тс ради этого. Имхо

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

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

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

Как-то у чуваков тесты и tdd не в почете видать )

Тесты в почёте, если они делаются без больших затрат (моки и т. п.). Но больше функциональные, например, когда тестируется вся функциональность целиком, без привязкт к методам. TDD... не знаю... Сколько я не старался, сколько я не стремился, а на практике получается, что пользы мало а затрат много, особенно в случае рефакторинга. И не всегда понятно, как тестировать один метод, если у него большой контекст.

ну, тогда нужно не забыть спросить про первый опыт!) послушал бы респонс

я, кстати, долго был приверженцем тдд, так как мне это казалось жуть как удобно и от этого было легко отталкиваться, но потом открестился)

Тесты в почёте, если они делаются без больших затрат (моки и т. п.). Но больше функциональные, например, когда тестируется вся функциональность целиком, без привязкт к методам. TDD... не знаю... Сколько я не старался, сколько я не стремился, а на практике получается, что пользы мало а затрат много, особенно в случае рефакторинга. И не всегда понятно, как тестировать один метод, если у него большой контекст.

я, кстати, долго был приверженцем тдд, так как мне это казалось жуть как удобно и от этого было легко отталкиваться, но потом открестился)

Это точно нужно на начальных этапах, чтобы руки выпрямились

да, вот когда почувствовал, что руки уже не совсем крюки, то решил откреститься, но, думаю, что не навсегда

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

благо сейчас я стал больше ко всему новому открыт, а не плеваться от всего подряд как дурачок

В бытность QA я обожал таких разрабов, потому что баги сыпались как из рога Амелфы). И можно было за неделю норму закрыть

Как QA перешедший в разрабы, без тестов не хочется работать. Потому как знаю, как кваки могут пить кровь. Так вот я им такого удовольствия не доставлю). В принципе, TDD работает, у меня получается с ними дружить и весьма неплохо

Мудрым стал ))

скорее перестал быть глупым..

Отбираешь хлеб у бывших коллег ))

Не одно и то же? )

Не одно и то же? )

Не тупить и поступать мудро - не одно и то же)

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

При чем тут тупняки? Речь про открытость новому. Отрицать новое по надуманным причинам - это не тупняки.

Тдд очень накладно практиковать - долго. И привыкать надо. Что ты подразумеваешь под большим контекстом?

Как QA перешедший в разрабы, без тестов не хочется работать. Потому как знаю, как кваки могут пить кровь. Так вот я им такого удовольствия не доставлю). В принципе, TDD работает, у меня получается с ними дружить и весьма неплохо

Ну... почему не функциональные тесты, а TDD? Проще проверить работоспособности системы целиком, и внешние интерфейсы не настолько подвержены извенениям, чем тестировать внутренние шестерёнки

Всем привет! У меня тут задачка стоит нужно прочекать домены на наличие в спам листах их ооочень много. На сайте dnsbl.info api не предоставляют. Нашел вот этот сайт dnsbl.smtp.bz но он позволяет чекать только по одному домену, как можно автоматизировать это есть идеи?

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