Ставишь промежуточную точку — получаешь меньшее время.
Емнип, у них там были критерии «комфортности» маршрута. Т.е., например, маршрут прокладывается так, чтобы на нем было меньше поворотов.
Я тоже знаю такие места, где можно проехать быстрее, но они требуют несколько лишних поворотов или проездов по небольшим улочкам, хоть я и не против. А яндекс по ним не прокладывает.
Да! Их легко находить на ощупь и легко перемещать палец с кнопок лево/право на вверх/вниз, т.к. ты всегда знаешь их относительное расположение. Я вообще очень расстроился, когда в новых клавиатурах стали ставить огромные кнопки лево/право. Но, похоже, что не все еще потеряно.
Ну это как-то странно. Во-первых, переносить в componentDidUpdate и обновлять там state — значит рендерить два раза. Во-вторых, MemoizedFlow хоть и позволяет в некоторых случаях писать компонент без стейта, все же представляет собой стейт, хоть и неявный. Так что stateless'ом тут не очень пахнет.
И await не возвращает промиз, в этом как раз его смысл. Вы здорово сбиваете с толку такими примерами, как будто это что-то новое, привнесенное await'ом, а это всего лишь использование await'а со старыми добрыми промизами.
И вообще, рекомендую http://es6-features.org/, как один из сайтов, где все новые фичи изложены кратко с минимальными примерами.
У редакса вообще много проблем с (де)сериализацией. Даже не надо такой экзотики как Map, достаточно вспомнить Date. При сериализации он становится строкой и строкой же десериализуется. И есть вполне рабочие методы избежать этого, которые, думается, можно применить и в вашем случае.
Но все же коллизии возможны, или вам о таких случаях ничего не известно? (кроме «минусовок»)
Дело даже не в авторских правах, есть и другие проблемы тогда. Вот пишете, что используете отпечаток для отображения обложки, текста, рекомендаций. Получается, что они могут бы неправильными, т.е. относиться к другой песне имеющей тот же отпечаток.
Возможны ли коллизии при таком способе нахождения отпечатка?
Что если некий трек заблокирован по требованию правообладателя, а отпечаток трека который я хочу загрузить волшебным образом с ним совпал, смогу ли я загрузить его?
Статья то нормальная, минусуют, думаю из-за неодобрения самого подхода. Как уже отметили выше, будут проблемы с eslint. Кроме того, управляющие теги затеряются среди разметочных, будет сложнее читать. Ну и, мое мнение, суть JSX как раз в том, чтобы свободно перемежать JS и HTML и чтобы это не выглядело плохо. И оно не выглядит.
Вот эти ошибки, упомянутые в разделе «как работать с API систем, который постоянно падают», что это за ошибки, можно привести какие-то примеры? Ведь если сервис упал и постинг поста (пардон) не работает, как это обойти?
С номерами домов конечно интересно, но почему вы думаете, что дизайн вывода их в вашем UI идеален и никому не захочется видеть их в другом виде?
Она и не должна быть идеальной. Я вот о чем: хочу, например, составить какой-то справочник организаций со списком адресов. Понятно, что я использую какой-то свой формат вывода, например пишу полностью «дом 13 корпус 2 строение 4». И вот из голосования я вижу, что в OSM были предложены такие варианты: «48АК2С1», «48Ак2с1», «48А к2с1», «48А к2 с1» и «48а к2 с1». Выбран был предпоследний. Соответственно, я могу написать код, который такой формат преобразует к моему. Проблема в том, что в реальности я могу встретить и другие форматы, а так же те, которые вообще не перечислены выше. И получается, что для того, чтобы корректно работать с этим значением, мне надо прикладывать больше усилий, чем думалось. И ладно еще справочник, его можно отредактировать после генерации, если что-то не распозналось. Сложнее, если надо реализовать поиск по адресу, например.
Я далеко не OSM гуру и, возможно, преувеличиваю проблему. Но наличие некого стандарта все же было бы большим плюсом.
В основе OSM тоже «просто картинки». Это просто набор точек, линий и полигонов. Осмысленность они приобретают только с добавлением тегов. Есть у этой area тег «дом»? Значит это дом.
Что меня смущало в OSM в свое время – так это несогласованность тегов. Если мне надо найти какую-то entity, которая может быть обозначена разными тегами, мне надо выполнять поиск, который бы все вариации учитывал? Или правило по написанию номеров домов. Да, я видел голосование, но все ли здания следуют выбранному варианту, или мне придется еще писать свой универсальный парсер номеров, чтобы потом в UI моего приложения показывать человекочитабельный номер дома. Получается, что я не могу просто взять и использовать данные OSM, надо писать какие-то обертки. Или я не прав и есть какое-то решение?
А почему её есть нельзя? Вижу такую надпись на пачках соли для ПММ. Может быть ее нельзя есть регулярно из-за того, что не йодированная или калия с прочими примесями мало, но ведь в принципе то я могу ее в тесто положить, например? Как раз для хлеба крупный помол №2 нужен, а в продаже не найти пока.
Она и есть полная, только для нее плагины с тем же функционалом, что в сателлитах (PHPStrorm, PyCharm, ...) выходят позднее. Поэтому она всегда слегка отсталая, но лично мне не всегда позарез нужен свежайший функционал.
Надо заметить, что в IDEA v12, кажется, не было возможности управлять venv'ами для питона, а в PyCharm'e тех лет, была. Однако IDEA v14 (может и v13) такое уже умеет и мне комфортно работать в ней. Всяко это более удобно, чем иметь две или более IDE. Так что попробуйте идею еще раз, вдруг нужный вам функционал там уже появился.
Да нет, WebStorm — это урезанный PHPStorm, а PyCharm — вообще для python'а. Я же просто купил полную идею и теперь все в одном месте, потому что у меня как веб, так и Java, так и Python, очень удобно.
Емнип, у них там были критерии «комфортности» маршрута. Т.е., например, маршрут прокладывается так, чтобы на нем было меньше поворотов.
Я тоже знаю такие места, где можно проехать быстрее, но они требуют несколько лишних поворотов или проездов по небольшим улочкам, хоть я и не против. А яндекс по ним не прокладывает.
Да! Их легко находить на ощупь и легко перемещать палец с кнопок лево/право на вверх/вниз, т.к. ты всегда знаешь их относительное расположение. Я вообще очень расстроился, когда в новых клавиатурах стали ставить огромные кнопки лево/право. Но, похоже, что не все еще потеряно.
У вас там корявое объяснение: «each await expression is a Promise in itself». Это утверждение эквивалентно такому коду: Хотя по факту он такой: И await не возвращает промиз, в этом как раз его смысл. Вы здорово сбиваете с толку такими примерами, как будто это что-то новое, привнесенное await'ом, а это всего лишь использование await'а со старыми добрыми промизами.
И вообще, рекомендую http://es6-features.org/, как один из сайтов, где все новые фичи изложены кратко с минимальными примерами.
(Данные скомпилированы из нескольких источников, где они слегка разнятся, поэтому ссылок не привожу.)
Дело даже не в авторских правах, есть и другие проблемы тогда. Вот пишете, что используете отпечаток для отображения обложки, текста, рекомендаций. Получается, что они могут бы неправильными, т.е. относиться к другой песне имеющей тот же отпечаток.
Что если некий трек заблокирован по требованию правообладателя, а отпечаток трека который я хочу загрузить волшебным образом с ним совпал, смогу ли я загрузить его?
Она и не должна быть идеальной. Я вот о чем: хочу, например, составить какой-то справочник организаций со списком адресов. Понятно, что я использую какой-то свой формат вывода, например пишу полностью «дом 13 корпус 2 строение 4». И вот из голосования я вижу, что в OSM были предложены такие варианты: «48АК2С1», «48Ак2с1», «48А к2с1», «48А к2 с1» и «48а к2 с1». Выбран был предпоследний. Соответственно, я могу написать код, который такой формат преобразует к моему. Проблема в том, что в реальности я могу встретить и другие форматы, а так же те, которые вообще не перечислены выше. И получается, что для того, чтобы корректно работать с этим значением, мне надо прикладывать больше усилий, чем думалось. И ладно еще справочник, его можно отредактировать после генерации, если что-то не распозналось. Сложнее, если надо реализовать поиск по адресу, например.
Я далеко не OSM гуру и, возможно, преувеличиваю проблему. Но наличие некого стандарта все же было бы большим плюсом.
В основе OSM тоже «просто картинки». Это просто набор точек, линий и полигонов. Осмысленность они приобретают только с добавлением тегов. Есть у этой area тег «дом»? Значит это дом.
Что меня смущало в OSM в свое время – так это несогласованность тегов. Если мне надо найти какую-то entity, которая может быть обозначена разными тегами, мне надо выполнять поиск, который бы все вариации учитывал? Или правило по написанию номеров домов. Да, я видел голосование, но все ли здания следуют выбранному варианту, или мне придется еще писать свой универсальный парсер номеров, чтобы потом в UI моего приложения показывать человекочитабельный номер дома. Получается, что я не могу просто взять и использовать данные OSM, надо писать какие-то обертки. Или я не прав и есть какое-то решение?
Надо заметить, что в IDEA v12, кажется, не было возможности управлять venv'ами для питона, а в PyCharm'e тех лет, была. Однако IDEA v14 (может и v13) такое уже умеет и мне комфортно работать в ней. Всяко это более удобно, чем иметь две или более IDE. Так что попробуйте идею еще раз, вдруг нужный вам функционал там уже появился.