учить язык чисто через погружение в его среду и большой(massive) и, желательно, "понимаемый"(comprehensive) "input" - "ввод"
Возвращаемся к пункту 4, тренируя понимание, мы натренируем понимание, но не говорение. "Выучить язык" — это получить сложный навык, в который входит не только "input" но и "output". Вы об этом, собственно, и говорите. Одного понимания недостаточно, если цель в том чтобы полноценно говорить. Так что предложенный вами метод наверняка работает, но это только часть паззла. Грамматика — это другая часть. Одно не отменяет второго, а дополняет. Есть и другие части, такие как произношение.
Напишите в личку или сюда, какие у вас страны, я их добавлю. Моя логика была в том чтобы таргетироваться только на тех, кто сможет оплатить сервис. Но возможно я не права и надо как-то иначе.
На самом деле ставить приложение совсем не обязательно (и я сейчас тоже поняла что не подсветила это на лендинге, добавлю), можно просто с браузера работать (десктоп или мобила), на мобиле ярлык добавить на https://app.patternly.ru/, да и всё. Разница с приложением только в том что не будут приходить пуши.
Там другой тип упражнений. См. п.4 из статьи и частично п.7. В моём тренажёре человек сам переводит предложения с русского на английский, текстом или голосом, надиктовывает один за другим на беглость и точность. У них же нужно выбирать из существующих слов (которые нужно сначала прочитать), да и голосового ввода нет.
Пусть хоть что-то напишет. Всё равно как это назвать. Суть в том чтобы другим людям было понятно (хотя бы примерно) что нужно сделать. Никто не говорит о том что нужно сделать идеально, я как раз и подчёркиваю что не надо. Но почему-то для многих выбор именно такой, либо идеально, либо никак. Раз заранее ясно что у них не получится сделать идеально (они ведь не специалисты), то значит не надо делать никак.
А по поводу самому писать -- ну по сути это интервьюирование человека, которому лень самому структурировать свои мысли. Я в статье и хочу донести до заказчиков что так не надо делать, тем более когда исполнителя нет, его только хочется найти, то и интервьюировать некому.
А насчёт вордпресса, я всегда говорю что всё что можно сделать на CMS, нужно делать на CMS. Никогда не возьмусь за работу, которую не считаю нужным делать кастомной разработкой.
Тут 2 варианта реализации я буду выбирать один из них с точки зрения того что именно подгружается и дальнейшей работы с этим. Если просто статическая инфа без поведения (для примера -- это может быть подгрузка логов), то HTML, если там что-то посложнее (например подгрузка событий в календарь), то JSON.
Именно так. Бесконечный скролл нужен для таких кейсов как инстаграм, дзен или маркет. Когда цель не в том чтобы человек нашёл то что ему нужно, а в том чтобы он залип, и думскроллил! Не может быть пользовательского сценария "хочу листать чтобы было красиво", есть пользовательский сценарий "хочу решить свою конкретную задачу, и чем быстрее тем лучше". Пагинация удобна тем что можно чётко увидеть сколько ты страниц пролистал и сколько осталось. Можно решить для себя "5 страниц посмотрю и уйду". С бесконечным скроллом не так, он придуман не для пользователей, а для сервиса чтобы поднимать его метрики!
То чем занимется автор этой ветки -- это подгон вопроса под ответ. Если пойти чуть дальше, пользователям не нужна динамичность, им даже красота не нужна. Им плевать перезагружается там что-то или нет. Им нужно чтобы было предсказуемо, привычно, просто, чтобы можно было задачу свою решить. Всё остальное надумано для того чтобы оправдать сложность реализации (и свою зарплату).
Кто-то думает что выбор стоит между "красиво и качественно" и "некрасиво и некачественно", но выбор стоит между "дёшево и сердито", и "монструозное поделие с багами, где надо чистить кеш и нажимать F5". А баги там сложно не засадить, нужна внимательность и перфекционизм. У большинства её нет, либо нет времени вылизывать. Поэтому имеем что имеем. Взять за пример рекламный кабинет фейсбука, всё сложное, рокетсайнс, но баг на баге. И там не с улицы фронтендеры работают. Ну может у местных хабравчан конечно повыше уровень, знают о чём говорят, и это просто и то просто, и проблема из пальца высосана.
Я написала достаточно ясно, что ajax не нужен, нужен переход на новую страницу, <a href='...?page=2'>, так понятней? При чём тут infinity scroll? Вы спросили про "Пользователь кликает на постраничнике следующую страницу", я на это и ответила.
Ага. 1) в корпорациях 2) там где действительно нужно приложение в браузере. Я об этом сразу и написала. Проблема в том что остальные используют инструмент не по назначению, и из-за этого теряют время и деньги. Всё.
Какая вероятность того что "стрельнет"? Ничего само по себе не стреляет. Обычно трафик покупают, и этот напор можно регулировать. Даже если есть виральные механики, там всё равно не будет взрывного роста. Это очень и очень большая редкость. Перемножаем вероятность "стрельнет" (p, близкое к нулю) на ресурсы которые нужно потратить чтобы это предусмотреть и сравниваем с перемноженной вероятностью (1-p) на ресурсы если не предусматривать. И выбираем.
Даже если эта вероятность сработает, то будут и деньги и мотивация чтобы что-то там переделать. Это априори не работа в стол. И не так оно страшно, даже если потребует времени.
Я была CTO в проекте с выручкой в миллион долларов, где сделала всё так как пишу. И нам даже лень переписывать было. Там и с точки зрения дизайна из-за постоянных изменений всё стало выглядеть так себе, мы называли его "франкенштейн". И ничего. Это всё не главное.
Вы пишете про реализацию, про готовые компотенты, но важно не это. Важно то какую задачу решает этот IT продукт. Задача может быть какой угодно. В рамках той области которую очертила изначально.
А если нагрузка вдруг возникнет, все переписывать?
Nice problem to have, к сожалению реальной жизни почти никогда не встречается. Намного же чаще встречается обратное, пока программисты занимаются технодрочерством, у стратапа заканчиваются деньги или мотивация, не добежав до первых пользователей.
Возвращаемся к пункту 4, тренируя понимание, мы натренируем понимание, но не говорение. "Выучить язык" — это получить сложный навык, в который входит не только "input" но и "output". Вы об этом, собственно, и говорите. Одного понимания недостаточно, если цель в том чтобы полноценно говорить. Так что предложенный вами метод наверняка работает, но это только часть паззла. Грамматика — это другая часть. Одно не отменяет второго, а дополняет. Есть и другие части, такие как произношение.
Напишите в личку или сюда, какие у вас страны, я их добавлю. Моя логика была в том чтобы таргетироваться только на тех, кто сможет оплатить сервис. Но возможно я не права и надо как-то иначе.
На самом деле ставить приложение совсем не обязательно (и я сейчас тоже поняла что не подсветила это на лендинге, добавлю), можно просто с браузера работать (десктоп или мобила), на мобиле ярлык добавить на https://app.patternly.ru/, да и всё. Разница с приложением только в том что не будут приходить пуши.
Там другой тип упражнений. См. п.4 из статьи и частично п.7. В моём тренажёре человек сам переводит предложения с русского на английский, текстом или голосом, надиктовывает один за другим на беглость и точность. У них же нужно выбирать из существующих слов (которые нужно сначала прочитать), да и голосового ввода нет.
Демо пока не сделала, осложняется тем что там есть голосовой ввод => транскрибация, его можно заабьюзить.
Есть скриншоты https://patternly.ru/blog/filosofiya-i-metodologiya-patternly/#что-предлагает-patternly и здесь https://patternly.ru/course/ содержимое тренажёра, все темы с примерами
Спасибо за такой обстоятельный комментарий! Очень полезно, мне нужно время на то чтобы вникнуть
В том-то и дело что спрашивать "Как успехи?" начинают на следующий день)
Пусть хоть что-то напишет. Всё равно как это назвать. Суть в том чтобы другим людям было понятно (хотя бы примерно) что нужно сделать. Никто не говорит о том что нужно сделать идеально, я как раз и подчёркиваю что не надо. Но почему-то для многих выбор именно такой, либо идеально, либо никак. Раз заранее ясно что у них не получится сделать идеально (они ведь не специалисты), то значит не надо делать никак.
Всё именно так.
А по поводу самому писать -- ну по сути это интервьюирование человека, которому лень самому структурировать свои мысли. Я в статье и хочу донести до заказчиков что так не надо делать, тем более когда исполнителя нет, его только хочется найти, то и интервьюировать некому.
Я
Спасибо за статью! Очень полезно.
Если выбор стоит не между "сделать из сайта" и "сделать нативно", а между "сделать из сайта" и "не сделать ничего", что выберите?
Свои покажите, а мы оценим.
А насчёт вордпресса, я всегда говорю что всё что можно сделать на CMS, нужно делать на CMS. Никогда не возьмусь за работу, которую не считаю нужным делать кастомной разработкой.
Тут 2 варианта реализации я буду выбирать один из них с точки зрения того что именно подгружается и дальнейшей работы с этим. Если просто статическая инфа без поведения (для примера -- это может быть подгрузка логов), то HTML, если там что-то посложнее (например подгрузка событий в календарь), то JSON.
Именно так. Бесконечный скролл нужен для таких кейсов как инстаграм, дзен или маркет. Когда цель не в том чтобы человек нашёл то что ему нужно, а в том чтобы он залип, и думскроллил! Не может быть пользовательского сценария "хочу листать чтобы было красиво", есть пользовательский сценарий "хочу решить свою конкретную задачу, и чем быстрее тем лучше". Пагинация удобна тем что можно чётко увидеть сколько ты страниц пролистал и сколько осталось. Можно решить для себя "5 страниц посмотрю и уйду". С бесконечным скроллом не так, он придуман не для пользователей, а для сервиса чтобы поднимать его метрики!
То чем занимется автор этой ветки -- это подгон вопроса под ответ. Если пойти чуть дальше, пользователям не нужна динамичность, им даже красота не нужна. Им плевать перезагружается там что-то или нет. Им нужно чтобы было предсказуемо, привычно, просто, чтобы можно было задачу свою решить. Всё остальное надумано для того чтобы оправдать сложность реализации (и свою зарплату).
Кто-то думает что выбор стоит между "красиво и качественно" и "некрасиво и некачественно", но выбор стоит между "дёшево и сердито", и "монструозное поделие с багами, где надо чистить кеш и нажимать F5". А баги там сложно не засадить, нужна внимательность и перфекционизм. У большинства её нет, либо нет времени вылизывать. Поэтому имеем что имеем. Взять за пример рекламный кабинет фейсбука, всё сложное, рокетсайнс, но баг на баге. И там не с улицы фронтендеры работают. Ну может у местных хабравчан конечно повыше уровень, знают о чём говорят, и это просто и то просто, и проблема из пальца высосана.
Ужас! Это просто невозможно вынести! Страница вместе с шапкой перезагружается! Как люди только жили раньше! Ещё и на медленном интернете. Треш.
Я написала достаточно ясно, что ajax не нужен, нужен переход на новую страницу, <a href='...?page=2'>, так понятней? При чём тут infinity scroll? Вы спросили про "Пользователь кликает на постраничнике следующую страницу", я на это и ответила.
Ага. 1) в корпорациях 2) там где действительно нужно приложение в браузере. Я об этом сразу и написала. Проблема в том что остальные используют инструмент не по назначению, и из-за этого теряют время и деньги. Всё.
Какая вероятность того что "стрельнет"? Ничего само по себе не стреляет. Обычно трафик покупают, и этот напор можно регулировать. Даже если есть виральные механики, там всё равно не будет взрывного роста. Это очень и очень большая редкость. Перемножаем вероятность "стрельнет" (p, близкое к нулю) на ресурсы которые нужно потратить чтобы это предусмотреть и сравниваем с перемноженной вероятностью (1-p) на ресурсы если не предусматривать. И выбираем.
Даже если эта вероятность сработает, то будут и деньги и мотивация чтобы что-то там переделать. Это априори не работа в стол. И не так оно страшно, даже если потребует времени.
Я была CTO в проекте с выручкой в миллион долларов, где сделала всё так как пишу. И нам даже лень переписывать было. Там и с точки зрения дизайна из-за постоянных изменений всё стало выглядеть так себе, мы называли его "франкенштейн". И ничего. Это всё не главное.
Вы пишете про реализацию, про готовые компотенты, но важно не это. Важно то какую задачу решает этот IT продукт. Задача может быть какой угодно. В рамках той области которую очертила изначально.
Nice problem to have, к сожалению реальной жизни почти никогда не встречается. Намного же чаще встречается обратное, пока программисты занимаются технодрочерством, у стратапа заканчиваются деньги или мотивация, не добежав до первых пользователей.