Самое неприятное в этом споре — быть с другой стороны. Выдают такие направления обычно на текущий или следующий день, когда запись по талонам уже вся расписана.
И вот, стоишь, весь такой не виноватый в криворукости системы, без записи и талона. А люди винят тебя, т.к. думают, что именно ты их задерживаешь.
Странно, что статья так много говорит о решении уравнений и ни слова о том, что учёные изобретали, по факту, pattern matching на стероидах нейронных сетях. Однако, если эта штука действительно работает как заявлено, то результат действительно крутой. И распознавание смысла сообщений стало на один шаг ближе, что тоже круто.
И поиск неугодных стал на один шаг ближе:( Это же Facebook.
Вы правы. Я считаю это платой за комплексность решения проблем в одной экосистеме.
В прошлых анонсах, JetBrains обещали открытость к расширению и, кажется, даже скриптинг (как был в YouTrack, для кастомной логики внутри самого YouTrack) на Kotlin. Если обещание исполнится, будет здорово.
Я не часто пишу на react, но вроде же можно было описать props компонента при помощи интерфейса и ts даже проверял такие места. Почему бы и не указать в этом же интерфейсе функцию как prop?
Есть такая тема, не очень популярная, к счастью или нет. В интерфейсе BPMS ребята пытались рисовать конфиг развёртывания приложения, связывая между собой микросервисы. Хотели запилить себе конструктор. Мол, сервисы написаны, параметризуем и будем фигачить. Не знаю уж взлетело ли, но сильно сомневаюсь.
Динамическая диспетчеризация (если я верно понял суть row polymorphism) обычно используются там, где писать ad-hoc реализацию слишком многословно или когда tagged union построить невозможно ввиду особенностей архитектуры проекта. Или там, где система типов не очень богатая (Java, C# и пр.).
Не уверен, насколько это применимо к Haskell, сужу по своему опыту кодирования на Rust. Частенько бывает что, отделяя абстракцию от реализации, разработчик получает ситуацию, когда итоговый union тип становится возможно построить лишь в проекте самого верхнего уровня иерархии. И чтобы обеспечить его использование, нужно либо обмазываться полиморфизмом сильнее (что весомо усложняет код), либо использовать динамическую диспетчеризацию.
Ну т.к. они разработаны для работы в контексте хуков, то, полагаю, даже модульные тесты будут похожи на интеграционные: нужно возвести окружение работающего react, написать тестовый компонент, использующий хук специальным для тестируемости образом, и уже для него писать тест.
А исправление бага потом back merge'ем подтягиваем в основную ветку. По крайней мере, мы. Не вижу ни единой причины не забирать в основную ветку фикс какого-то бага, оставляя его неисправленным.
А чего мелочиться? Был никому не нужный Google+, импортозаменим на никому не нужную Ауру. Просто чтобы было. Чтобы пользовались, видимо, цель не стояла:)
Не поделитесь ссылочками на источник?
Простите мне мой тон, но мне кажется, что вы заново изобрели Принцип инверсии зависимостей.
Самое неприятное в этом споре — быть с другой стороны. Выдают такие направления обычно на текущий или следующий день, когда запись по талонам уже вся расписана.
И вот, стоишь, весь такой не виноватый в криворукости системы, без записи и талона. А люди винят тебя, т.к. думают, что именно ты их задерживаешь.
И бензин! Бензин обязательно подорожает!
Странно, что статья так много говорит о решении уравнений и ни слова о том, что учёные изобретали, по факту, pattern matching на
стероидахнейронных сетях. Однако, если эта штука действительно работает как заявлено, то результат действительно крутой. И распознавание смысла сообщений стало на один шаг ближе, что тоже круто.И поиск неугодных стал на один шаг ближе:( Это же Facebook.
innerHTML ломает все подписки на события. Да и вообще, заставляет браузер делать кучу ненужной работы по парсингу и рендерингу.
Вы правы. Я считаю это платой за комплексность решения проблем в одной экосистеме.
В прошлых анонсах, JetBrains обещали открытость к расширению и, кажется, даже скриптинг (как был в YouTrack, для кастомной логики внутри самого YouTrack) на Kotlin. Если обещание исполнится, будет здорово.
Интересно, а работоспособно ли решение в контексте SSR?
Этот код выглядит как глобальный статичный стейт на всё приложение. Очень хотелось бы, чтобы это было не так. Иначе SSR не полетит.
Я не часто пишу на react, но вроде же можно было описать props компонента при помощи интерфейса и ts даже проверял такие места. Почему бы и не указать в этом же интерфейсе функцию как prop?
UPD. Действительно, можно.
https://codesandbox.io/s/focused-field-3oq5w?file=/src/App.tsx
Про markdown всё довольно прозаично — его надо SSR'ить для индексации ботами.
Твою мать, это великолепно! Буду своим показывать теперь:)
Есть такая тема, не очень популярная, к счастью или нет. В интерфейсе BPMS ребята пытались рисовать конфиг развёртывания приложения, связывая между собой микросервисы. Хотели запилить себе конструктор. Мол, сервисы написаны, параметризуем и будем фигачить. Не знаю уж взлетело ли, но сильно сомневаюсь.
Динамическая диспетчеризация (если я верно понял суть row polymorphism) обычно используются там, где писать ad-hoc реализацию слишком многословно или когда tagged union построить невозможно ввиду особенностей архитектуры проекта. Или там, где система типов не очень богатая (Java, C# и пр.).
Не уверен, насколько это применимо к Haskell, сужу по своему опыту кодирования на Rust. Частенько бывает что, отделяя абстракцию от реализации, разработчик получает ситуацию, когда итоговый union тип становится возможно построить лишь в проекте самого верхнего уровня иерархии. И чтобы обеспечить его использование, нужно либо обмазываться полиморфизмом сильнее (что весомо усложняет код), либо использовать динамическую диспетчеризацию.
Адепты WASI присоединяются к зловещему потиранию ручек.
Ну т.к. они разработаны для работы в контексте хуков, то, полагаю, даже модульные тесты будут похожи на интеграционные: нужно возвести окружение работающего react, написать тестовый компонент, использующий хук специальным для тестируемости образом, и уже для него писать тест.
А исправление бага потом back merge'ем подтягиваем в основную ветку. По крайней мере, мы. Не вижу ни единой причины не забирать в основную ветку фикс какого-то бага, оставляя его неисправленным.
А чего мелочиться? Был никому не нужный Google+, импортозаменим на никому не нужную Ауру. Просто чтобы было. Чтобы пользовались, видимо, цель не стояла:)
И за очередной забытой справкой будет отправлять не женщина за столом в %госструктураname%, а робот. Инновации в массы!
Думаю, 360˚ это не "сам себе", а, скорее "со всех сторон". Такой, простите, gangbang feedback получается.
Flux приехал в мир C++?