Простите, видимо я допустил ошибки при оценке аудитории. Своим саркастическим комментарием я лишь хотел донести, что не нужно в столь ярких красках укорять за использование англицизмов, когда у самого комментирующего ошибка на ошибке. Это странно предъявлять к другим завышенные ожидания при заниженных своих. Не говоря уже о том, что у слова "адаптация" несколько другое, более общее значение, нежели у "onboarding"
P.S. При чём тут внимательность я не понял. Как будто автоматически ничего не значащий ответ
Как же надоело, когда «по-русски» пишут не через дефис! И «та-дам». И слово «пишете» во втором абзаце тут кстати через букву «е», т. к. первое спряжение. Пишите правильно, пожалуйста :)
А если поставить сложный уровень, то целевая аудитория увидит, что "сложно" и много текста, и пройдёт мимо. А те, кто это всё и так знают, удивятся, собственно, а к чему это всё? Я вот увидел, например, на канале Android Broadcast пост, где написано "очень много про потоки в одной статье". О, думаю, надо почитать, захожу и вижу такое заманчивое описание (почти цитата):
"Что надо знать, чтобы успешно применять многопоточность? Есть некоторые неудобные для изложения куски в разных описаниях потоков и того, что с ними связано, которые остаются нераскрытыми или вообще пропускаются."
О, интересно, какие же. Читаю, а тут лишь написано, что параллельность это всего лишь термин, который обозначает очень быстрое переключение и прерывание потоков. А ещё есть race condition и deadlock. И всё. И возникает вопрос, а на что я потратил время? Кто ЦА? Что нового узнал? Ведь есть же курс по Операционным системам от хекслета (не воспринимайте как рекламу), есть статьи на хабре: 1. https://habr.com/ru/companies/otus/articles/549814/ 2. https://habr.com/ru/companies/clrium/articles/488260/ 3. https://habr.com/ru/articles/40227/ И наверняка ещё куча подобных материалов, которые и нагляднее, и более насыщены информацией
Термин "многословность" тут как раз в негативном ключе, потому что кажется, будто это всё можно описать в нескольких предложениях. Самое сложное в этой статье, это понять описание примера:
"Пусть декодер некоторого JPEG-подобного формата читает данные из файла и декодирует их, записывая готовые для отображения фреймы в циркулярный буфер на 10 (на N) фреймов."
Возникают вопросы, что за JPEG-подобный формат, откуда и во что декодирует, что за отображения фреймов, что за циркулярный буфер. Была бы картинка - было бы проще (или пример упростить, или терминами не нагружать, опять же, зависит от ЦА, пример в целом понятный, но не сходу)
И напоследок. В грамотно составленной статье (как правило) в введении описывается проблема, которая решается (например, "Хочу рассказать о том, за счёт чего достигается параллельное выполнение программ..."), а в заключении краткая выжимка результатов (например, "Таким образом, мы увидели, что под параллельностью подразумевается..."). Это не то, чтобы что-то обязательное, скорее правило хорошего тона, позволяющее упростить чтение и восприятие информации
P.S. Если статья кому-то действительно окажется полезной - то я только рад. Я лишь изложил свою точку зрения, которая необязательно отражает истину
Уровень статьи не выглядит как сложный. Многословный - да, сложный - нет :) Тут же просто база описана (как мне казалось, довольно известная и почти очевидная)
На 03.12.2019 18:50 пример также не работает, т.к. поле street не строковое, а составное. Вероятно, сервис поменял формат возвращаемых данных по сравнению с моментом написания предыдущего комментария. В качестве быстрого фикса можно создать такой класс:
class Street {
@SerializedName("number")
private int number;
@SerializedName("name")
private String name;
}
и в классе Location у переменной street поменять тип со стринга на Street
Ну, корутины это пока ещё не полноценная замена Rx, так что знать хотя бы основы не помешает) Название статьи согласен, подобрано не самым лучшим образом, довольно быстро всё меняется, но таков был оригинал, дата, напомню — сентябрь 2017-го. Следующие части уже этого года, хоть и без корутин, к сожалению.
Простите, видимо я допустил ошибки при оценке аудитории. Своим саркастическим комментарием я лишь хотел донести, что не нужно в столь ярких красках укорять за использование англицизмов, когда у самого комментирующего ошибка на ошибке. Это странно предъявлять к другим завышенные ожидания при заниженных своих. Не говоря уже о том, что у слова "адаптация" несколько другое, более общее значение, нежели у "onboarding"
P.S. При чём тут внимательность я не понял. Как будто автоматически ничего не значащий ответ
Как же надоело, когда «по-русски» пишут не через дефис! И «та-дам». И слово «пишете» во втором абзаце тут кстати через букву «е», т. к. первое спряжение. Пишите правильно, пожалуйста :)
А перевод второй части?
А если поставить сложный уровень, то целевая аудитория увидит, что "сложно" и много текста, и пройдёт мимо. А те, кто это всё и так знают, удивятся, собственно, а к чему это всё? Я вот увидел, например, на канале Android Broadcast пост, где написано "очень много про потоки в одной статье". О, думаю, надо почитать, захожу и вижу такое заманчивое описание (почти цитата):
"Что надо знать, чтобы успешно применять многопоточность? Есть некоторые неудобные для изложения куски в разных описаниях потоков и того, что с ними связано, которые остаются нераскрытыми или вообще пропускаются."
О, интересно, какие же. Читаю, а тут лишь написано, что параллельность это всего лишь термин, который обозначает очень быстрое переключение и прерывание потоков. А ещё есть race condition и deadlock. И всё. И возникает вопрос, а на что я потратил время? Кто ЦА? Что нового узнал? Ведь есть же курс по Операционным системам от хекслета (не воспринимайте как рекламу), есть статьи на хабре:
1. https://habr.com/ru/companies/otus/articles/549814/
2. https://habr.com/ru/companies/clrium/articles/488260/
3. https://habr.com/ru/articles/40227/
И наверняка ещё куча подобных материалов, которые и нагляднее, и более насыщены информацией
Термин "многословность" тут как раз в негативном ключе, потому что кажется, будто это всё можно описать в нескольких предложениях. Самое сложное в этой статье, это понять описание примера:
"Пусть декодер некоторого JPEG-подобного формата читает данные из файла и декодирует их, записывая готовые для отображения фреймы в циркулярный буфер на 10 (на N) фреймов."
Возникают вопросы, что за JPEG-подобный формат, откуда и во что декодирует, что за отображения фреймов, что за циркулярный буфер. Была бы картинка - было бы проще (или пример упростить, или терминами не нагружать, опять же, зависит от ЦА, пример в целом понятный, но не сходу)
И напоследок. В грамотно составленной статье (как правило) в введении описывается проблема, которая решается (например, "Хочу рассказать о том, за счёт чего достигается параллельное выполнение программ..."), а в заключении краткая выжимка результатов (например, "Таким образом, мы увидели, что под параллельностью подразумевается..."). Это не то, чтобы что-то обязательное, скорее правило хорошего тона, позволяющее упростить чтение и восприятие информации
P.S. Если статья кому-то действительно окажется полезной - то я только рад. Я лишь изложил свою точку зрения, которая необязательно отражает истину
Уровень статьи не выглядит как сложный. Многословный - да, сложный - нет :) Тут же просто база описана (как мне казалось, довольно известная и почти очевидная)
Тема accessibility при переопределении onTouchEvent не раскрыта
"постоянное" время тоже никто не говорит. Скорее, "константное"
Есть ли прирост в производительности в данном подходе от того, что предлагал Евгений Мацюк? В каком случае стоит переходить на этот?
и в классе Location у переменной street поменять тип со стринга на Street