Люди реально с нуля учат язык на С1 за 3 месяца, а уж 100-150 слов за вечер — вообще легчайше.
Я вполне верю, что таким вот способом можно выучить хоть десять тысяч слов — запоминают же десятки тысяч знаков после запятой числа пи.
Вопрос другой. Реально ли это поможет выучить язык? Потому что есть сомнения — уметь пользоваться языком, говорить на нем, писать, читать — это не то же самое, что быть ходячим словарем.
Понятно. То есть он просто не даёт использовать отдельные возможности языка.
Ладно, это все дело вкуса, полагаю. Мне лично не доводилось писать огромный энтерпрайз на миллионы строк, на каком-нибудь angular. Так что из сложностей с отсутствием типов не возникало.
Вообще, по мне, на фронте сложное — это интерфейсы. Их состояния и их вёрстка. Делая какой-нибудь аналог экселя в браузере, заколебешься с двумя вещами — чтобы одна часть состояния не влияла на другую (что по большей части решает либа для реактивного интерфейса), и чтобы браузер нормально отрисовывал десятки тысяч элементов, которые ведут себя по-разному, но должны быть единым целым (тот же эксель примером — какие-то колонки должны быть фиксированными, какие-то прокручиваться, какие-то прокручиваться в одну сторону и быть фиксированными в другой, и тд) и при этом не лагать от избытка логики. Типизация тут — от силы пара процентов от всех проблем, вроде статической погрешности.
Вот на беке да, допускаю что ts очень полезен может быть.
Я не слишком в ts разбираюсь, поэтому вопрос. Этот keyof позволит заменить все вхождения User.name на User.firstName "одной кнопкой", вне зависимости от того, как это реализовано — вызовом метода напрямую, использованием переменной с названием метода как ключ хеша, и тд?
Мне вот кажется, что на такой анализ ИДЕшки не способны. Может конечно, я в прошлом застрял — ничем сложнее саблайма или атома не пользуюсь уже давно.
А как вы, интересно, автоматизируете те ситуации, когда написано не `User.name`, а `User[«name»]` или `let field=«name»; User[field]`? Когда название поля или метода возвращается из функции? Когда экземпляр отправляется аргументом в функцию и там у него что-то вызывается, в зависимости от фазы луны, клиентского запроса или значения в бд?
Ответ — никак. Покрывать функционал тестами и проверять, что после рефакторинга они не упали.
Под эту статью очень подходит музыка из деревни дураков. Блокировки сами по себе — это уже достаточно плохо, а с такой кривой реализацией — вообще кошмар.
Вот эти протухшие домены, к примеру. Ок, когда из-за них блокируется Википедия — это одно. Довольно быстро об этом узнают и чинят. А если кто-нибудь будет ими блокировать своих конкурентов в нишевых отраслях, сайтами которых не пользуется вся страна? И плевать на них будет этому роскомнадзору, через месяц может почешется.
Да как бы по факту ничего революционного в итоге нет.
Простой апи — перечисление полей, которые нужно вернуть:
/users?fields=id,name,..
Сложный апи — используй силу json, Люк:
POST /users/search.json
{
search: {...}
output_format: {...}
}
, в {...} можно запихнуть конфигурацию любого уровня сложности
Потом такие «а давайте одну точку входа сделаем!» — не вопрос:
POST /graphql
{
users(...search_params...): {
...
}
}
По сути тот же json, просто другой синтаксис — но фейсбук же не идет проторенными путями, верно?
Жирный плюс — они написали спецификацию. Надо её теперь дополнить и стандартизировать.
К примеру, одни фильтруют так:
{
users(id: 12) {
id
}
}
Другие — так:
{
users(id: {eq: 12}) {
id
}
}
Третьи так:
{
users(_eq: [id, 12]) {
id
}
}
Сделать единый формат, который будет поддерживать большинство из возможностей SQL WHERE, сделать инструменты на фронте и на сервере, которые это все генерируют и транслируют (типа hasura), и даже домохозяйка сможет создавать крутые SPA сайты. Мир, дружба, жвачка, и безработные айтишники, которые раньше делали «сайт под ключ за 5к рублей». А еще — генерация крутых админок под любой бекенд, был бы только в наличии дизайн приятный :)
Пожалуй, возьму паузу. Надо бы поподробней посмотреть на реализации. Из коробки я помню подобное только в эластик серче — автоматически создаётся новая версия при апдейте.
Это мы на ровном месте усложняем наше приложение — как в разработке, так и в конечном интерфейсе. Васе и Пете не нужна версионность, им просто нужна возможность совместно управлять контентом, к примеру, интернет магазина. Partial update это обеспечивает в большинстве случаев, без дополнительных затрат.
Как мы узнаем, что есть конфликты? Вася открыл форму редактирования и ушёл к начальству уточнять вопрос. В это время Игорь отредактировал пару полей. Через 10 минут Вася приходит, редактирует поля в форме и сохраняет их — на сервер идёт запрос и обновляется сущность целиком — Вася не знал, что пара полей уже изменилась. А бэк подумал, что Вася изменил больше полей, чем это есть на самом деле. В итоге изменения Игоря откатились по факту.
Как именно вы в таком сценарии оптимистичную блокировку внедрите? Сам принцип какой будет? Синхронизировать данные вебсокетами, как в гугл доксе? Открывая форму редактирования, отправлять серверу дополнительный запрос вида «сейчас я начну редачить вот эту сущность»?
Upd А, кажется, понял. Отправлять не только новые значения, но и старые — чтобы сервер сравнивал, совпадают ли эти старые значения, перед обновлением. Мороки это, конечно, добавит знатно ;)
Смысл partial update в том, что пока Вася обновляет описание сущности, Игорь добавляет туда фотографии или меняет цену, или название. Если обновлением перезаписывать все поля, то есть большой шанс откатывать таким образом чьи-то изменения.
Ха-ха, вот и вы попались в ловушку бесполезного спора. Судя по всему, товарищ не просто упертый, он никогда не отказывается от своих слов. И если совершенно случайно он скажет, что снег чёрный, то он начнёт переопределять слово чёрный, вместо того, чтобы сказать «сорян, я ошибся, имелось ввиду — белый».
Ему сказали «не используй квантор всеобщности», причём уже два раза. Вместо этого он начал переопределять свои слова, чтобы прошлые высказывания стали верными.
Таких людей лучше тупо игнорировать — на моем примере можно увидеть, что конструктивный диалог построить не получится.
А, теперь дошло. Действительно, в одну кучу смешали. По хорошему, сюда бы валидацию сделать толковую, как в grape, к примеру: обязательное/опциональное, список значений, возможность null-значения, min-max, регулярки, и так далее. Можно было бы парсить схему и на фронте не только генерировать, но и автоматически валидировать формы.
В мутациях отправляешь те поля, которые нужно изменить. Если не нужно изменять значение поля — не отправляешь его. Если отправляешь в качестве значения null, то и в бд запишется null, если валидация позволяет. Вы хотите, чтобы можно было отправлять поля со значениями null, а они при этом не меняли своего значения?
В реляционных базах null — это отдельный вид значения, это не 0 и не пустая строка. Вот и GraphQL это отражает. Поэтому для какой-нибудь схемы {id: String!} соответствует значение {id: ""}, и не соответствует {id: null}.
Удивительная логика. То есть работодатель перед тем, как взять кого-либо на работу не стесняется предъявлять будущему сотруднику список требований, а когда то же самое делает потенциальный сотрудник — это, получается, грех смертный? Удивительная логика.
Во-первых, не работодатель, а университет.
Во-вторых, даже если работодатель. Для гугла, принимающего тысячу человек в год через десятки рекруретов в различных офисах по всему миру, есть смысл разработать единую политику. Для одного человека такого смысла нет, это какой-то выверт психики вроде «почему это им можно, а мне нельзя, я тоже буду». Да на здоровье, только выглядишь при этом глупо — так же глупо, как маленькие организации, пытающиеся скопировать всю бюрократию с больших фирм. Или программисты, использующие те или иные технологии просто потому что их используют в гугле. Для таких даже специальную фразу придумали: «ты не гугл».
Да нет же. Решение тут — создать некую систему быстрого распознавания «спам/не спам», что автор и сделал.
Если бы он рассказал про реализацию этой системы, я бы почитал с интересом. Как именно распознавал, какие письма в какую папку класть, что использовал, какие результаты. Байесовский фильтр, нейронные сети, генетический алгоритм или еще что-то интересное.
А сейчас это «смотрите на меня, какой я весь из себя, ко мне на хромой козе не подъедешь».
Вот видите. А писали бы рекрутёры нормальные письма — глядишь и чаще бы откликался на призыв сменить работу.
Это считается плюсом? Оглянитесь — куча таких, «быстро меняющих работу» — наговнокодил и сбежал через полгода, чтобы не поддерживать своего франкенштейна.
Картинка с xkcd нерелевантна.
А по мне — очень даже релевантна. Вон, уже еще одну тему на хабре создали, где говорят, что эти его требования — чушь. И то, за что он дает баллы, давать не надо. И снимать не надо за то, за что он снимает. Вот и резко +2 стандарта появились. Не считая предыдущих. И на какой из них ориентироваться рекрутёрам?)
Я вполне верю, что таким вот способом можно выучить хоть десять тысяч слов — запоминают же десятки тысяч знаков после запятой числа пи.
Вопрос другой. Реально ли это поможет выучить язык? Потому что есть сомнения — уметь пользоваться языком, говорить на нем, писать, читать — это не то же самое, что быть ходячим словарем.
Понятно. То есть он просто не даёт использовать отдельные возможности языка.
Ладно, это все дело вкуса, полагаю. Мне лично не доводилось писать огромный энтерпрайз на миллионы строк, на каком-нибудь angular. Так что из сложностей с отсутствием типов не возникало.
Вообще, по мне, на фронте сложное — это интерфейсы. Их состояния и их вёрстка. Делая какой-нибудь аналог экселя в браузере, заколебешься с двумя вещами — чтобы одна часть состояния не влияла на другую (что по большей части решает либа для реактивного интерфейса), и чтобы браузер нормально отрисовывал десятки тысяч элементов, которые ведут себя по-разному, но должны быть единым целым (тот же эксель примером — какие-то колонки должны быть фиксированными, какие-то прокручиваться, какие-то прокручиваться в одну сторону и быть фиксированными в другой, и тд) и при этом не лагать от избытка логики. Типизация тут — от силы пара процентов от всех проблем, вроде статической погрешности.
Вот на беке да, допускаю что ts очень полезен может быть.
Я не слишком в ts разбираюсь, поэтому вопрос. Этот keyof позволит заменить все вхождения User.name на User.firstName "одной кнопкой", вне зависимости от того, как это реализовано — вызовом метода напрямую, использованием переменной с названием метода как ключ хеша, и тд?
Мне вот кажется, что на такой анализ ИДЕшки не способны. Может конечно, я в прошлом застрял — ничем сложнее саблайма или атома не пользуюсь уже давно.
Ответ — никак. Покрывать функционал тестами и проверять, что после рефакторинга они не упали.
Может, это Typescript нужен лишь мартышкам, неспособным писать без поддерживающего их код каркаса?)
Под эту статью очень подходит музыка из деревни дураков. Блокировки сами по себе — это уже достаточно плохо, а с такой кривой реализацией — вообще кошмар.
Вот эти протухшие домены, к примеру. Ок, когда из-за них блокируется Википедия — это одно. Довольно быстро об этом узнают и чинят. А если кто-нибудь будет ими блокировать своих конкурентов в нишевых отраслях, сайтами которых не пользуется вся страна? И плевать на них будет этому роскомнадзору, через месяц может почешется.
https://lesswrong.ru/w/Пацифизм_губит_ухоженные_сады
Ну, если на то пошло, первая строка читается почти как нормальное предложение, слева направо.
Простой апи — перечисление полей, которые нужно вернуть:
Сложный апи — используй
силуjson, Люк:, в {...} можно запихнуть конфигурацию любого уровня сложности
Потом такие «а давайте одну точку входа сделаем!» — не вопрос:
По сути тот же json, просто другой синтаксис — но фейсбук же не идет проторенными путями, верно?
Жирный плюс — они написали спецификацию. Надо её теперь дополнить и стандартизировать.
К примеру, одни фильтруют так:
Другие — так:
Третьи так:
Сделать единый формат, который будет поддерживать большинство из возможностей SQL WHERE, сделать инструменты на фронте и на сервере, которые это все генерируют и транслируют (типа hasura), и даже домохозяйка сможет создавать крутые SPA сайты. Мир, дружба, жвачка, и безработные айтишники, которые раньше делали «сайт под ключ за 5к рублей». А еще — генерация крутых админок под любой бекенд, был бы только в наличии дизайн приятный :)
Как именно вы в таком сценарии оптимистичную блокировку внедрите? Сам принцип какой будет? Синхронизировать данные вебсокетами, как в гугл доксе? Открывая форму редактирования, отправлять серверу дополнительный запрос вида «сейчас я начну редачить вот эту сущность»?
Upd А, кажется, понял. Отправлять не только новые значения, но и старые — чтобы сервер сравнивал, совпадают ли эти старые значения, перед обновлением. Мороки это, конечно, добавит знатно ;)
Ему сказали «не используй квантор всеобщности», причём уже два раза. Вместо этого он начал переопределять свои слова, чтобы прошлые высказывания стали верными.
Таких людей лучше тупо игнорировать — на моем примере можно увидеть, что конструктивный диалог построить не получится.
В мутациях отправляешь те поля, которые нужно изменить. Если не нужно изменять значение поля — не отправляешь его. Если отправляешь в качестве значения null, то и в бд запишется null, если валидация позволяет. Вы хотите, чтобы можно было отправлять поля со значениями null, а они при этом не меняли своего значения?
В реляционных базах null — это отдельный вид значения, это не 0 и не пустая строка. Вот и GraphQL это отражает. Поэтому для какой-нибудь схемы {id: String!} соответствует значение {id: ""}, и не соответствует {id: null}.
Во-вторых, даже если работодатель. Для гугла, принимающего тысячу человек в год через десятки рекруретов в различных офисах по всему миру, есть смысл разработать единую политику. Для одного человека такого смысла нет, это какой-то выверт психики вроде «почему это им можно, а мне нельзя, я тоже буду». Да на здоровье, только выглядишь при этом глупо — так же глупо, как маленькие организации, пытающиеся скопировать всю бюрократию с больших фирм. Или программисты, использующие те или иные технологии просто потому что их используют в гугле. Для таких даже специальную фразу придумали: «ты не гугл».
Если бы он рассказал про реализацию этой системы, я бы почитал с интересом. Как именно распознавал, какие письма в какую папку класть, что использовал, какие результаты. Байесовский фильтр, нейронные сети, генетический алгоритм или еще что-то интересное.
А сейчас это «смотрите на меня, какой я весь из себя, ко мне на хромой козе не подъедешь».
Это считается плюсом? Оглянитесь — куча таких, «быстро меняющих работу» — наговнокодил и сбежал через полгода, чтобы не поддерживать своего франкенштейна.
А по мне — очень даже релевантна. Вон, уже еще одну тему на хабре создали, где говорят, что эти его требования — чушь. И то, за что он дает баллы, давать не надо. И снимать не надо за то, за что он снимает. Вот и резко +2 стандарта появились. Не считая предыдущих. И на какой из них ориентироваться рекрутёрам?)