сравнить две строки без побайтового либо посимвольного прохода по ним невозможно.
Можно. Посмотрите на String::intern.
Вполне можно добиться того, что в куче не будет одинаковых строк. Т.е., если в разных местах в коде использовать одинаковое строковое значение, то оно будет указывать на один и тот же объект.
Я не знаю, насколько это поведение надежно, но данные оптимизации действительно имеют место быть при компиляции. Хотя я лично на них не полагаюсь, и пишу в коде string1.equals(string2) вместо string1 == string2. Но второй вариант тоже, в теории, будет работать достаточно стабильно.
«теория лингвистической относительности» это полный бред.
Я не могу сказать, насколько сильно язык определяет наше сознание и ход наших мыслей, но то что восприятие мира может отличаться в зависимости от языка, на котором думаешь, — это не такой и бред. И я уверен, что многие из тех, кто изучали языки, замечали это. Особенно, когда знаешь несколько языков.
Для русских, например, определенные и неопределенные артикли — это боль. И в нашем мышлении мы их не используем. Но многие европейцы мыслят этими артиклями. Для них они естественны.
Одна из причин, почему испанский язык для англичан может быть сложен, потому что вместо привычного «to be» у них два глагола: ser и estar. Один говорит о том, что свойство постоянное и не меняется (имя, например), второе, что свойство не постоянное (голоден, например). Но сами испанцы думают с этих категориях. И для них они естественны и встроены в процесс мышления.
У японцев, чей язык вообще мало похож на европейский, есть несколько вариантов союза «и», которые выражают либо исчерпывающие списки, либо не исчерпывающие (т.е. представленное перечисление не полно).
Используемые цвета могут различаться. Мы используем «голубой» и «синий», а в английском, как правило, это просто «blue».
И т.д., и т.п.
Поэтому цитата из статьи кажется мне очень даже правдоподобной:
язык определяет сознание, то есть люди воспринимают мир неодинаково, потому что лингвистические категории родного языка накладывают ограничения и даже определяют мышление.
Я не преподаватель и ориентируюсь только на личный опыт. Я без проблем слушаю аудиокниги на английском, немецком и испанском. Но говорю только на английском. Для меня «пассивный опыт» (чтение, слушание) не трансформируется в навык говорить.
А сейчас на первых словах сразу ясно что робот, сбрасываю.
Когда звонит даже не оператор, а робот, и просит оставаться на линии и подождать живого оператора — это вообще за гранью добра и зла. Альфа-банк таким злоупотребляет.
Потому что это не нормальные деловые отношения. Не надо брать на себя чужие зоны ответственности. Если руководство забраковало идею, нужно принять это решение. Не надо решать за других людей. Да, возможно, это неправильное решение. Но делать «благую работу» вопреки ему — это неправильно.
В командах приходится работать с большим количеством людей. Многие из которых не всегда принимают корректные решения. Везде всегда кажется, что кто-то что-то решил не так. Но нужно с этим жить, а не делать по своему. Максимум, что можно сделать — это выразить свое мнение. Или сменить работу. Но игнорировать чужие решения в их зоне ответственности — это не тру.
Далее, это просто неблагодарная работа. Премию за это вряд ли выпишут. Более того, если это всплывет, руководство вообще может отреагировать весьма негативно. Потому что в их глазах вы делаете не то, что должны.
Ну, и конечно, такая деятельность — она вызывает большое чувство обиды и неудовлетворенности. Если пытаться сделать все что возможно, но в рамках рабочих нормальных отношений, — то чувства обиды не будет.
Нужно кооперироваться и уважать чужие решения. Даже если кажется, что они неверны.
В действительности, я начал полностью переписывать систему практически с 0. Пришлось это делать тайно от руководства.
Не надо так делать.
Я искренне уважаю стремление автора вытянуть проект, его полную погруженность в работу и неиссякаемый энтузиазм. Но в тайне переписывать систему — это, я считаю, ошибка.
Разработчик не должен думать за бизнес и принимать решение за бизнес. Да, он может высказать свое мнение, предоставить свою экспертизу, выразить сомнение, проявить инициативу. Но без одобрения менеджмента делать крупный кусок работы — за это никто спасибо не скажет. Более того, это не очень-то и этично. Это как сказать прямым текстом: «Товарищ менеджер, ты сам не понимаешь, что ты делаешь. Поэтому я буду принимать решения за тебя, с тобой не посоветовавшись». Не надо решать за менеджмент, что делать.
К тому же, из текста для меня совсем не очевидно, почему проект провалился. Может, при текущем маркетинге, дизайне и фичах, даже если бы все летало, проект бы это не спасло.
Большой словарный запас — это отлично. Но только в том случае, когда вы умеете правильно им распоряжаться. Ведь что толку знать 20 000 слов, если вы не можете объяснить знакомому американцу, как доехать до вашего дома?
Есть толк. Можно смотреть фильмы и сериалы, слушать аудио-книги и радио.
Не все учат иностранные для бизнеса и путешествий.
Я уверен, что есть много людей таких, как я, кому просто нравится читать/слушать художественную литературу на иностранных языках. Чтобы делать это комфортно, нужно пассивно знать чудовищное количество слов (десятки тысяч). 80% из этих слов мне вряд ли когда-либо придется использовать в речи.
Я считаю, что создавать сайты, способные работать без JS, вполне возможно.
Прикладывать силы для разработки/тестирования веб-приложений, которые могут работать без js — бесполезная трата времени и денег. Пользователей, которые отключают у себя JS — единицы.
Это же веб, а не App Store для JavaScript, мы должны быть уверены, что все всегда работает на любом устройстве с самыми базовыми функциями.
Нет. Мы должны быть уверены, что наша ЦА может посмотреть наш сайт. Ито, не вся. Если незначительный процент продолжает использовать совсем устаревшие браузеры, то чаще всего дешевле проститься с этими пользователями.
Непонятно, зачем автор вообще этим занималась. Но спасибо за перевод.
Даже если допустить, что reduce работает в два раза быстрее, чем filter + map, то для большинства проектов — это все равно не нужная микро-оптимизация, которая вообще не будет заметна. А читаемость кода страдает.
Подменить домен/поддомент нельзя. Но можно же пользователя никуда со своего сайта и не редиректить.
1) Пользователь в выдаче гугла перешел на сайт evilSite.com/
2) Этот сайт запушил в историю 2 стейта = «evilSite.com/googleClone» и «evilSite.com/main». URL в поисковой строке браузера в этот момент = «evilSite.com/main».
3) Пользователь жмет назад, попадает на клон гугла («evilSite.com/googleClone»).
В теории, если пользователь совсем не смотрим, что там в URL и копия сделана супер качественно, то может сработать.
А иногда корпоративные стандарты написания кода заставляют делать что-то, что не поддаётся внутренней логике разработчика.
const int TEN=10; // As if the value of 10 will fluctuate...
Конечно, если так называть константы, то не увидишь в этом логики. Нормальными и полезными были бы названия: MAX_STUDENT_COUNT, SUCCESS_CODE, MAIN_GATE_ID, etc.
После окончания курсов я осознал, что многие знания это многие печали. Если раньше я просто знал, что ничего не знаю, то теперь начал осознавать, что именно я не знаю.
so true. Чем больше материала изучаешь, тем больше знаешь о том, чего не знаешь.
Это вы зря. Во-первых, это реально удобно на практике. Если каждому элементу енама соответствует какое-то значение или даже поведение (в Java для enum элементов можно определить метод), то удобно этот аттрибут или поведение сохранить в самом енаме.
Во-вторых, с теоретической точки зрения это тоже приветствуется. Таким образом без лишних телодвижений реализуются паттерны state и strategy, что позволяет заменить условную логику полиморфизмом. Вместо switch и if просто делегируем часть функциональности енаму. Про то, что полиморфизм > условная логика, в последнее десятилетие не писал только ленивый.
Это отличная фича в Java. И мне этого очень не хватает в Typescript.
Можно. Посмотрите на String::intern.
Вполне можно добиться того, что в куче не будет одинаковых строк. Т.е., если в разных местах в коде использовать одинаковое строковое значение, то оно будет указывать на один и тот же объект.
Я не знаю, насколько это поведение надежно, но данные оптимизации действительно имеют место быть при компиляции. Хотя я лично на них не полагаюсь, и пишу в коде string1.equals(string2) вместо string1 == string2. Но второй вариант тоже, в теории, будет работать достаточно стабильно.
Я не могу сказать, насколько сильно язык определяет наше сознание и ход наших мыслей, но то что восприятие мира может отличаться в зависимости от языка, на котором думаешь, — это не такой и бред. И я уверен, что многие из тех, кто изучали языки, замечали это. Особенно, когда знаешь несколько языков.
Для русских, например, определенные и неопределенные артикли — это боль. И в нашем мышлении мы их не используем. Но многие европейцы мыслят этими артиклями. Для них они естественны.
Одна из причин, почему испанский язык для англичан может быть сложен, потому что вместо привычного «to be» у них два глагола: ser и estar. Один говорит о том, что свойство постоянное и не меняется (имя, например), второе, что свойство не постоянное (голоден, например). Но сами испанцы думают с этих категориях. И для них они естественны и встроены в процесс мышления.
У японцев, чей язык вообще мало похож на европейский, есть несколько вариантов союза «и», которые выражают либо исчерпывающие списки, либо не исчерпывающие (т.е. представленное перечисление не полно).
Используемые цвета могут различаться. Мы используем «голубой» и «синий», а в английском, как правило, это просто «blue».
И т.д., и т.п.
Поэтому цитата из статьи кажется мне очень даже правдоподобной:
Видимо, автор позже решил, что 10 минут — это не достаточно тру и хардкор. Хотя, разумеется, и за 10 минут это никто не напишет.
Когда звонит даже не оператор, а робот, и просит оставаться на линии и подождать живого оператора — это вообще за гранью добра и зла. Альфа-банк таким злоупотребляет.
Если нужно еще уметь писать/говорить на нем, то этого однозначно мало.
Потому что это не нормальные деловые отношения. Не надо брать на себя чужие зоны ответственности. Если руководство забраковало идею, нужно принять это решение. Не надо решать за других людей. Да, возможно, это неправильное решение. Но делать «благую работу» вопреки ему — это неправильно.
В командах приходится работать с большим количеством людей. Многие из которых не всегда принимают корректные решения. Везде всегда кажется, что кто-то что-то решил не так. Но нужно с этим жить, а не делать по своему. Максимум, что можно сделать — это выразить свое мнение. Или сменить работу. Но игнорировать чужие решения в их зоне ответственности — это не тру.
Далее, это просто неблагодарная работа. Премию за это вряд ли выпишут. Более того, если это всплывет, руководство вообще может отреагировать весьма негативно. Потому что в их глазах вы делаете не то, что должны.
Ну, и конечно, такая деятельность — она вызывает большое чувство обиды и неудовлетворенности. Если пытаться сделать все что возможно, но в рамках рабочих нормальных отношений, — то чувства обиды не будет.
Нужно кооперироваться и уважать чужие решения. Даже если кажется, что они неверны.
Не надо так делать.
Я искренне уважаю стремление автора вытянуть проект, его полную погруженность в работу и неиссякаемый энтузиазм. Но в тайне переписывать систему — это, я считаю, ошибка.
Разработчик не должен думать за бизнес и принимать решение за бизнес. Да, он может высказать свое мнение, предоставить свою экспертизу, выразить сомнение, проявить инициативу. Но без одобрения менеджмента делать крупный кусок работы — за это никто спасибо не скажет. Более того, это не очень-то и этично. Это как сказать прямым текстом: «Товарищ менеджер, ты сам не понимаешь, что ты делаешь. Поэтому я буду принимать решения за тебя, с тобой не посоветовавшись». Не надо решать за менеджмент, что делать.
К тому же, из текста для меня совсем не очевидно, почему проект провалился. Может, при текущем маркетинге, дизайне и фичах, даже если бы все летало, проект бы это не спасло.
Есть толк. Можно смотреть фильмы и сериалы, слушать аудио-книги и радио.
Не все учат иностранные для бизнеса и путешествий.
Я уверен, что есть много людей таких, как я, кому просто нравится читать/слушать художественную литературу на иностранных языках. Чтобы делать это комфортно, нужно пассивно знать чудовищное количество слов (десятки тысяч). 80% из этих слов мне вряд ли когда-либо придется использовать в речи.
Не хочу придираться к словам, но исключение никогда не подтверждает правило.
Прикладывать силы для разработки/тестирования веб-приложений, которые могут работать без js — бесполезная трата времени и денег. Пользователей, которые отключают у себя JS — единицы.
Нет. Мы должны быть уверены, что наша ЦА может посмотреть наш сайт. Ито, не вся. Если незначительный процент продолжает использовать совсем устаревшие браузеры, то чаще всего дешевле проститься с этими пользователями.
Непонятно, зачем автор вообще этим занималась. Но спасибо за перевод.
1) Пользователь в выдаче гугла перешел на сайт evilSite.com/
2) Этот сайт запушил в историю 2 стейта = «evilSite.com/googleClone» и «evilSite.com/main». URL в поисковой строке браузера в этот момент = «evilSite.com/main».
3) Пользователь жмет назад, попадает на клон гугла («evilSite.com/googleClone»).
В теории, если пользователь совсем не смотрим, что там в URL и копия сделана супер качественно, то может сработать.
Конечно, если так называть константы, то не увидишь в этом логики. Нормальными и полезными были бы названия: MAX_STUDENT_COUNT, SUCCESS_CODE, MAIN_GATE_ID, etc.
Извиняюсь за занудство в юмористическом посте)
so true. Чем больше материала изучаешь, тем больше знаешь о том, чего не знаешь.
Во-вторых, с теоретической точки зрения это тоже приветствуется. Таким образом без лишних телодвижений реализуются паттерны state и strategy, что позволяет заменить условную логику полиморфизмом. Вместо switch и if просто делегируем часть функциональности енаму. Про то, что полиморфизм > условная логика, в последнее десятилетие не писал только ленивый.
Это отличная фича в Java. И мне этого очень не хватает в Typescript.