В статье слишком много «захардкоженно». Можно было бы один раз написать что-то вроде «жестко вшитых» (в скобочках указать hardcoded) и не использовать этот термин больше.
А будет «правильное» решение? Или вы ждете ответа от комментаторов?
В принципе идея верна, если канал ненадежный, протокол должен организовать repetions (повторения). Если же ошибок очень много, то все повторения могут завершиться с ошибкой и тогда что? Можно попробовать уменьшать размер пакета (динамически?), чтобы увеличить вероятность успешной передачи повторения. Десять раз слать бит с повторением — это, извините, тупо. Плюс не решает проблемы с пропущенным битом (вы ждете получения 10).
Для обнаружения пропущенных битов можно использовать таймаут, если что-то началов приходить, расчитать через сколько времени макс придет последний бит, чтобы завершить передачу. В этом случае необходимо знать длину пакета, либо пакеты всегда фиксированной длины, либо с заголовком. А что если заголовок получен не правильно?
Можно разбить пакет на 2: заголовок и данные. Получатель должен ответить ACK на заголовок, иначе данные не шлются. Если получатель послал ACK, который из-за ошибке не был получен, то опять можно использовать таймаут (после отсылки ACK), чтобы заметить, что данные не шлются и снова ожидать заголовок.
Нужно отработать автоматизм в восприятии и воспроизведении большого количества наиболее часто употребляемых коротких шаблонов языка
Это достигается за счет прослушивания «незнакомых» текстов в которых полно «новых» слов и встречаются конструкции, которые вы уже выучили. Сложный текст (например, что-то юридическое) понимаешь процентов на 10%, но зато «слышишь» знакомые фразы и выученные слова и по ним «пытаешься» (зачастую не удачно, но это нормально в курсе обучения) понять о чем речь.
Кстате, это используется на экзамене. В слушании (и чтении тоже) дают что-то, что вы не должны понимать на 100% в принципе, но если вы поймете то, что должны (т.к. выучили на протяжении курсов), то сможете ответить на экзаменационные вопросы.
Песни? Будет адски сложно подобрать песни, удовлетворяющие этому условию. Прослушивать случайные песни даст ровно 0 к навыку «слышания».
Но американцы вживую так и говорят, примерно такими фразами, и там не только интонация, а еще и жаргон.
Умение говорить фразами — это уж слишком начальный уровень. Понимание структуры предложения и умение «вертеть» словами/словосочетаниями, используя их в правильной форме — вот что нужно. Дайте человеку самые базовые конструкции языка + немного теории, чтобы он мог с ними «играться» правильно и эксперементировать (в последнем случае понадобиться ментор, чтобы указать на ошибки). Углубляйте, комбинируйте… В принципе песни могут тоже быть нескольких уровней, детские песни должны быть попроще, но начинать с них противоречит идее взять «известные и любимые песни», а без них мотивации, как вы полагаете, не откуда взяться.
Первую песню, смысл которой требовалось хотя бы приблизительно понимать, на курсах мы услышали через добрых 3 сотни часов занятий. Песни имеют к языку очень слабое отношение, я об этом.
Чтобы говорить нужно выучить много «готовых» конструкций, например вводных предложений: «я с вам полностью согласен», «насколько мне известно» и т.д… В песнях их нет, т.к. опять же, в песне важен ритм, рифма… Попробуйте разобрать какую-нибудь песню, увидите что пользы от знания текста песен очень мало. «Happy birthday to you» — ок, раз в год пригодится ;)
В статье вы сделали упор на технической части, как организовать процесс и тд., но проблема как-раз в обосновании. Диалоги на порядок важнее в лингафонных курсах, чем песни. Можно выучить язык (уметь разговаривать) и при этом совершенно не уметь разбирать слова песни на слух, т.к. это два разных навыка.
Это вы сами придумали что ли? На ком-то/чем-то тестировалось или просто голая теория?
В песнях произношение часто искажается: более быстрые или наоборот распевные слоги, ударение не туда, про интонацию молчу. Строение предложений тоже подгоняется под ритм. По сути вы предлагаете более простой способ заучивать фразы, «my heart will go on», «i like to be free» и т.д, но не более.
П.Ц.: негатив наверное из-за того, что 2 года использовал Rosetta Stone метод с близким к нулю результатам, сейчас пошел на груповые языковые курсы у носителя (она не говорит на русском), когда коллектив, клевая (мотивирующая) училка, веселая атмосфера, курс обучения написанный профессионалами и отточенный на тысячах уже освоивших язык… и прогресс пошел. Не понимаю теперь, зачем нужные все эти новые методики.
Hard work — тяжелая работа (см. синонимы). Судя по статье, «тяжелой» может быть только «тяжелая физически». Особенно «понравилось» (в кавычках) правило:
Тяжелая работа — это такая работа, которую другие делать не хотят
у нас в офисе никто не хочет заниматься документацией, делает ли это работу тяжелой физически? Не думаю.
В английском «hard work» это такое же широкоприменимое словосочетание, как и наше «тяжелая работа» и не надо пытаться подогнать его под определения. Попробуйте объяснить «легкая работа» и зайдете в тот же тупик, с теми же надуманными правилами. Просто потому, что каждый понимает словосочетание по своему и у него нет четкого определения по типу «было затрачено 100500 джоулей/ньютонов/пироженых с ванилью/петя-часов».
Да, я все еще осмеливаюсь утверждать, что троллинга тут не было. Был вопрос, который «не понравился» определенной аудитории. Все еще думаю, что вопрос уместен и не только мне будет интересно узнать ответ на него.
Спасибо. «Узкие юниксовые круги» видимо думают, что остальной мир пользуется текстовым редактором больше чем гуглем? Смутило сравнение с гуглем: "даже Vim еще не существовал. Все еще не могу понять, это сарказм типа «даже Norton Commander еще не существовал» или всерьез?
Вам, наверное, будет неудержимо смешно, но я в жизни им не пользовался, а его тут всуе наряду с гуглем упоминают. Стало интересно, что за зверь. И да, можно погуглить так, что останешься без ответа (к слову, первый ответ гугля по «vim» у меня какой-то vim online, модное слово «онлайн» появилось относительно недавно, потому не смотрел).
Заминусили, т.к. решили, что я тролю? Обидно, ну да ладно. Продолжайте веселиться.
CS1643 Not all code paths return a value in lambda expression
Правило простое, если лямбду поместить в { } (блок кода?), например, то она автоматически становится анонимной функцией и снова требует ключевое слово return:
MyDeleg @delegate = x => { return x + "world!"; };
Ага, в статье с заголовком «алгоритм», его-то и забыли завезти. Это конечно лучше, чем полная неспособность решить задачу (кто-бы спорил), но решить ее «как-нибудь» и запилить статью — даже не знаю. Отпишитесь ниже те, кто вникнул и нашел рассказанное полезным или интересным (хотя каюсь, первые абзацы захватили развитием сюжета). Прямо аж самому захотелось написать статью побесполезнее…
Хочется добавить, что решение проблемы (необходимость скриптовать некие сценарии) с помощью CodeDOM не совсем верно в общем случае (а случай в статье как раз общий, ни слова о конкретном сценарии).
Полезность примера выводящего «Hello world» в данном случае тоже близка с 0.
Единственно что обьяснили — это как скормить исходник и получить список ошибок, а это, извините, на статью не тянет, тема не раскрыта вообще от слова «полностью».
Я в свое время (эмм… десять лет назад) использовал CodeDOM для пре-компиляции формул (вызывался метод, тело которого пользователь писал на C#, методу передавался список входных/выходных параметров, которые можно было использовать в вычислениях и логике и возвращать результат), с появление Roslyn это конечно смешно (хотя уверен новичкам сгодилось), и тут эта статья…
С удовольствием полюбовался еще раз, сообщаю: на 2 картинке верхний жук обходит релиз чтобы катить его к тестерам (на 3й он поворачивается к собеседнику) на 4й он обдумывает свой ответ и план действий, на 6й оказывается что нижний жук тоже катит свой релиз к тестерам… Очень жизненно: пообщались, посетовали и продолжили работу дальше (а что делать? дома семья, дети голодные, против системы идти себе в ущерб).
Не понятно как пришли к такому выводу. Перечисленные пункты никакого отношения к выводу не имеют. Стоит ли читать дальше?
В принципе идея верна, если канал ненадежный, протокол должен организовать repetions (повторения). Если же ошибок очень много, то все повторения могут завершиться с ошибкой и тогда что? Можно попробовать уменьшать размер пакета (динамически?), чтобы увеличить вероятность успешной передачи повторения. Десять раз слать бит с повторением — это, извините, тупо. Плюс не решает проблемы с пропущенным битом (вы ждете получения 10).
Для обнаружения пропущенных битов можно использовать таймаут, если что-то началов приходить, расчитать через сколько времени макс придет последний бит, чтобы завершить передачу. В этом случае необходимо знать длину пакета, либо пакеты всегда фиксированной длины, либо с заголовком. А что если заголовок получен не правильно?
Можно разбить пакет на 2: заголовок и данные. Получатель должен ответить ACK на заголовок, иначе данные не шлются. Если получатель послал ACK, который из-за ошибке не был получен, то опять можно использовать таймаут (после отсылки ACK), чтобы заметить, что данные не шлются и снова ожидать заголовок.
И т.д.
Это достигается за счет прослушивания «незнакомых» текстов в которых полно «новых» слов и встречаются конструкции, которые вы уже выучили. Сложный текст (например, что-то юридическое) понимаешь процентов на 10%, но зато «слышишь» знакомые фразы и выученные слова и по ним «пытаешься» (зачастую не удачно, но это нормально в курсе обучения) понять о чем речь.
Кстате, это используется на экзамене. В слушании (и чтении тоже) дают что-то, что вы не должны понимать на 100% в принципе, но если вы поймете то, что должны (т.к. выучили на протяжении курсов), то сможете ответить на экзаменационные вопросы.
Песни? Будет адски сложно подобрать песни, удовлетворяющие этому условию. Прослушивать случайные песни даст ровно 0 к навыку «слышания».
Умение говорить фразами — это уж слишком начальный уровень. Понимание структуры предложения и умение «вертеть» словами/словосочетаниями, используя их в правильной форме — вот что нужно. Дайте человеку самые базовые конструкции языка + немного теории, чтобы он мог с ними «играться» правильно и эксперементировать (в последнем случае понадобиться ментор, чтобы указать на ошибки). Углубляйте, комбинируйте… В принципе песни могут тоже быть нескольких уровней, детские песни должны быть попроще, но начинать с них противоречит идее взять «известные и любимые песни», а без них мотивации, как вы полагаете, не откуда взяться.
Первую песню, смысл которой требовалось хотя бы приблизительно понимать, на курсах мы услышали через добрых 3 сотни часов занятий. Песни имеют к языку очень слабое отношение, я об этом.
Чтобы говорить нужно выучить много «готовых» конструкций, например вводных предложений: «я с вам полностью согласен», «насколько мне известно» и т.д… В песнях их нет, т.к. опять же, в песне важен ритм, рифма… Попробуйте разобрать какую-нибудь песню, увидите что пользы от знания текста песен очень мало. «Happy birthday to you» — ок, раз в год пригодится ;)
В статье вы сделали упор на технической части, как организовать процесс и тд., но проблема как-раз в обосновании. Диалоги на порядок важнее в лингафонных курсах, чем песни. Можно выучить язык (уметь разговаривать) и при этом совершенно не уметь разбирать слова песни на слух, т.к. это два разных навыка.
В песнях произношение часто искажается: более быстрые или наоборот распевные слоги, ударение не туда, про интонацию молчу. Строение предложений тоже подгоняется под ритм. По сути вы предлагаете более простой способ заучивать фразы, «my heart will go on», «i like to be free» и т.д, но не более.
П.Ц.: негатив наверное из-за того, что 2 года использовал Rosetta Stone метод с близким к нулю результатам, сейчас пошел на груповые языковые курсы у носителя (она не говорит на русском), когда коллектив, клевая (мотивирующая) училка, веселая атмосфера, курс обучения написанный профессионалами и отточенный на тысячах уже освоивших язык… и прогресс пошел. Не понимаю теперь, зачем нужные все эти новые методики.
у нас в офисе никто не хочет заниматься документацией, делает ли это работу тяжелой физически? Не думаю.
В английском «hard work» это такое же широкоприменимое словосочетание, как и наше «тяжелая работа» и не надо пытаться подогнать его под определения. Попробуйте объяснить «легкая работа» и зайдете в тот же тупик, с теми же надуманными правилами. Просто потому, что каждый понимает словосочетание по своему и у него нет четкого определения по типу «было затрачено 100500 джоулей/ньютонов/пироженых с ванилью/петя-часов».
раздражает.
Заминусили, т.к. решили, что я тролю? Обидно, ну да ладно. Продолжайте веселиться.
CS1643 Not all code paths return a value in lambda expression
Правило простое, если лямбду поместить в { } (блок кода?), например, то она автоматически становится анонимной функцией и снова требует ключевое слово return:
Полезность примера выводящего «Hello world» в данном случае тоже близка с 0.
Единственно что обьяснили — это как скормить исходник и получить список ошибок, а это, извините, на статью не тянет, тема не раскрыта вообще от слова «полностью».
Я в свое время (эмм… десять лет назад) использовал CodeDOM для пре-компиляции формул (вызывался метод, тело которого пользователь писал на C#, методу передавался список входных/выходных параметров, которые можно было использовать в вычислениях и логике и возвращать результат), с появление Roslyn это конечно смешно (хотя уверен новичкам сгодилось), и тут эта статья…