Alex Baumgertner alexbaumgertner
Тут перечислены не законы, последние слово всегда за здравым смыслом. Тут перечислены лишь направление, куда надо стремиться. Принципы, которые должны помочь, когда не знаешь, что выбрать.
- Пользователь. Если что-то сильно мешает UX или есть критическая ошибка, то в первую очередь мы спасаем пользователей. Для этого иногда надо взять ответственность на себя, переубедить толпу, написать плохой код.
This is the CFP for my React Rally talk, which was eventually accepted and given here: https://www.youtube.com/watch?v=nyFHR0dDZo0.
If you are a first time speaker, my CFP advice for new speakers is here.
Functional-reactive libraries like RxJS make it easy to understand how data changes, giving us tools to declaratively handle events and manage state. But while our render methods react to state changes, React isn’t reactive. Instead, we write imperative event-handlers, and trip up on gotchas like async setState and race conditions. Why? In this talk we build a Reactive React to show the difference between the "push" and "pull" paradigms of data flow and understand why React chooses to manage Scheduling as a core Design Principle, enabling awesome features like async rendering and Suspense!
Theme: This talk is a deep dive into React's core design principle around scheduling. Instead of abstr
| // These two are equivalent | |
| !A && !B == !(A || B) | |
| // Also these two | |
| !A || !B == !(A && B) |
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
- https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API
- https://developer.mozilla.org/en-US/docs/Web/API/SpeechSynthesis
- https://developer.mozilla.org/en-US/docs/Web/API/SpeechRecognition
- https://developer.mozilla.org/en-US/docs/Web/API/SpeechGrammar
- https://www.w3.org/TR/jsgf/
- https://w3c.github.io/speech-api/speechapi.html
- Представься: краткая информация о себе – имя, место работы, чем занимаешься, можно фото для тех, кто будет смотреть слайды отдельно
- План доклада: несколько пунктов (лучше не более 5) о чём будет доклад. Это могут быть главы доклада (кстати, составление плана может помочь грамотнее структурировать доклад ещё при создании)
- Зачем: кратко рассказать, чем то, о чем рассказываешь в докладе, может быть полезно остальным – и разработчикам, и руководителям, и клиентам (можно акцентироваться на аудитории конкретной конфы – например если там есть дизайнеры, бэкенды, то упомянуть, что они могут узнать из доклада)
- Итоги: в конце доклада ещё раз пройтись по плану и подвести итог по каждому пункту – что узнали, чему научились
- Контакты: как слушатель и тот кто смотрит слайды может связаться и задать вопрос
Чатра ищет разработчика
Привет!
Мы в Чатре ищем разработчика. Чатра — это современный чат для сайтов. У нас классный продукт, сделанный с любовью и вниманием к деталям, небольшая дружная команда и больше десяти тысяч клиентов в Северной Америке и Европе.
Не хватает одного — прекрасного разработчика или разработчицы, желающей присоединиться к нашей команде.
| version: '2' | |
| services: | |
| api: | |
| volumes: | |
| - "nfsmount:${CONTAINER_DIR}" | |
| volumes: | |
| nfsmount: | |
| driver: local | |
| driver_opts: |