(Если кто не застал – это прикол времён Фидонета, когда буква 'Н' сжиралась, если я не путаю, GoldEdом. Ещё буква 'р' была проклята – в результате зачастую даже раскладку русификатора делали так, что гни заменялись на латинские 'H' и 'p' соответственно... Думаю, если сейчас погуглить русские слова с такой заменой – найдётся много текстов с артефактами тех времён).
Автор очень странный. Первым делом делается санитайзинг или эскейпинг пользовательского ввода (это всё равно жёсткая необходимость и это уже решает проблему), а потом можно удовлетворять своё любопытство, выясняя, откуда там 0x02.
Не удивлюсь, если они там отфильтровали только 0x02, а если юзер скопипастит туда 0x03 – опять что-то навернётся. А то и вообще придёт маленький Бобби Тэйблс (xkcd#327).
Очень много слов вокруг очень простой и привычной всем концепции. Да, конечно, typescript делает её удобнее за счёт автоматического сужения типов – но то же самое он делает и для прочих type guards (типа булевых функций с пометкой x is T – имело смысл сравнивать с ними)
Для работы с опытными программистами – как правило, будет только мешать. А для работы с джунами нужен опытный программист, иначе они такого наворотят...
Я как-то думал, что продактов растят из людей с уже большим опытом – либо большой опыт программиста, либо большой опыт в бизнесе.
Есть чувство, что для тех, кто знает используемую терминологию и привычен к используемому матаппарату, её содержание тривиально (выписать все формулы займёт меньше времени, чем прочитать статью), а прочим надо пояснять, что такое преобразование Парка-Горева, преобразование Кларке и т.п.
Я не минусил, но, увидев такие вопросы на собесе, задал бы встречный вопрос: у вас такое в коде? И, напротив, собеседуя кого-то – больше порадовался бы не пониманию смысла этого, а воплю "какой ... это написал?"
Ну и, соответственно, на этом этапе примеры на собесе можно отдать под рефакторинг: типа, не нравится? А как бы вы написали? Тут и понимание закоулков языка проверите (хотя оно и не столь критично), и умение писать читаемый код.
А вот совсем беда – если человек такие фрагменты кода просто не заметит. Особенно если он их поймёт неправильно (но и если правильно – тоже не супер).
Почему большинство языков проектируется по "принципу наименьшего удивления", а тут то цепные сравнения с оператором "is", то множественное наследование с "кто первый встал, того и тапки" (если б я в реальном коде увидел такое наследование – я б орал на написавшего его... А вообще в приличных местах множественное наследование допускается или от интерфейсов, или от миксинов, чтобы не допустить такой неоднозначности), то иммутабельных/хэшируемых массивов нет (ну тут ладно, такую хрень всё равно в голову бы не пришло написать).
Так эксперимент-то вы провели? А то лично для меня выглядит весьма вероятным, что минификация кода или не влияет на эффективность его разбора LLM вообще (грубо говоря, занимаемая токеном память не зависит от его длины), или влияет в лучшую сторону (имя токена используется как дополнительная информация, вроде его типа. Эта гипотеза подтверждается тем, что автокомплит в XCode и VS Code реагирует уже на имя переменной).
Ты, возможно, себя сравниваешь с одноклассниками, одногруппниками, коллегами или друзьями, у которых это легко получается, а у тебя нет. Но здесь нужно понимать, что у каждого свой темп, и твоему мозгу просто нужно больше времени.
Так это и значит нет способностей. Если тебе надо в 3-5 раз больше сил и времени, чем другим – как ещё это назвать?
Понятно, что терпение и труд всё перетрут, но себя надо оценивать здраво.
Справиться можно любым, но некоторые инструменты удобнее.
Плюс в данном случае недостаточно настроить что-то себе, чтобы история приняла нормальный вид – нужно форсить определённую политику использования git (как минимум – отсутствие fast-forward merge в мастер, тогда можно будет просматривать линейную историю в виде "только текущая ветка + только первый родитель в мерже") на всю команду.
Периодически плачусь, что в индустрии выжил гит, а не меркуриал с его полноценными ветками (где ветка – это не указатель на её голову, а совокупность всех сделанных в неё коммитов). В меркуриале чистая история мастера (ну или релизной ветки) получалась сама собой, а в гите нужны костыли.
МЕЯ ВИДО? (c)
(Если кто не застал – это прикол времён Фидонета, когда буква 'Н' сжиралась, если я не путаю, GoldEdом. Ещё буква 'р' была проклята – в результате зачастую даже раскладку русификатора делали так, что гни заменялись на латинские 'H' и 'p' соответственно... Думаю, если сейчас погуглить русские слова с такой заменой – найдётся много текстов с артефактами тех времён).
Автор очень странный. Первым делом делается санитайзинг или эскейпинг пользовательского ввода (это всё равно жёсткая необходимость и это уже решает проблему), а потом можно удовлетворять своё любопытство, выясняя, откуда там 0x02.
Не удивлюсь, если они там отфильтровали только 0x02, а если юзер скопипастит туда 0x03 – опять что-то навернётся. А то и вообще придёт маленький Бобби Тэйблс (xkcd#327).
Это не sum type, а его частный случай.
Очень много слов вокруг очень простой и привычной всем концепции. Да, конечно, typescript делает её удобнее за счёт автоматического сужения типов – но то же самое он делает и для прочих type guards (типа булевых функций с пометкой x is T – имело смысл сравнивать с ними)
А куда можно применить джуниор продакта?
Для работы с опытными программистами – как правило, будет только мешать. А для работы с джунами нужен опытный программист, иначе они такого наворотят...
Я как-то думал, что продактов растят из людей с уже большим опытом – либо большой опыт программиста, либо большой опыт в бизнесе.
Прошу прощения, а на кого ориентирована статья?
Есть чувство, что для тех, кто знает используемую терминологию и привычен к используемому матаппарату, её содержание тривиально (выписать все формулы займёт меньше времени, чем прочитать статью), а прочим надо пояснять, что такое преобразование Парка-Горева, преобразование Кларке и т.п.
Обычно вроде не 30, побольше. И в обе стороны: закладываются, что часы могут быть немного сбиты.
Я не минусил, но, увидев такие вопросы на собесе, задал бы встречный вопрос: у вас такое в коде? И, напротив, собеседуя кого-то – больше порадовался бы не пониманию смысла этого, а воплю "какой ... это написал?"
Ну и, соответственно, на этом этапе примеры на собесе можно отдать под рефакторинг: типа, не нравится? А как бы вы написали? Тут и понимание закоулков языка проверите (хотя оно и не столь критично), и умение писать читаемый код.
А вот совсем беда – если человек такие фрагменты кода просто не заметит. Особенно если он их поймёт неправильно (но и если правильно – тоже не супер).
Спасибо, убили всё желание пользоваться Питоном.
Почему большинство языков проектируется по "принципу наименьшего удивления", а тут то цепные сравнения с оператором "is", то множественное наследование с "кто первый встал, того и тапки" (если б я в реальном коде увидел такое наследование – я б орал на написавшего его... А вообще в приличных местах множественное наследование допускается или от интерфейсов, или от миксинов, чтобы не допустить такой неоднозначности), то иммутабельных/хэшируемых массивов нет (ну тут ладно, такую хрень всё равно в голову бы не пришло написать).
Так эксперимент-то вы провели? А то лично для меня выглядит весьма вероятным, что минификация кода или не влияет на эффективность его разбора LLM вообще (грубо говоря, занимаемая токеном память не зависит от его длины), или влияет в лучшую сторону (имя токена используется как дополнительная информация, вроде его типа. Эта гипотеза подтверждается тем, что автокомплит в XCode и VS Code реагирует уже на имя переменной).
Так это и значит нет способностей. Если тебе надо в 3-5 раз больше сил и времени, чем другим – как ещё это назвать?
Понятно, что терпение и труд всё перетрут, но себя надо оценивать здраво.
Где-то в 2009 будет, потерпите немного :-)
Homebrew или MacPorts на выбор.
Что это за поток сознания?
Это для апдейтов :-)
Мне кажется, наоборот. В эпоху асимметричного шифрования стыдно делать захардокоженные пароли для закладок)
Нигде не вылезет. Просто смысла ноль.
Мне тоже нравится – доводилось пользоваться значительно менее удобными vcs. Но mercurial нравился больше.
Справиться можно любым, но некоторые инструменты удобнее.
Плюс в данном случае недостаточно настроить что-то себе, чтобы история приняла нормальный вид – нужно форсить определённую политику использования git (как минимум – отсутствие fast-forward merge в мастер, тогда можно будет просматривать линейную историю в виде "только текущая ветка + только первый родитель в мерже") на всю команду.
Async2 – это тот же механизм, что реализован в Swift (где await порой может ничего не стоить), или другой?
Периодически плачусь, что в индустрии выжил гит, а не меркуриал с его полноценными ветками (где ветка – это не указатель на её голову, а совокупность всех сделанных в неё коммитов). В меркуриале чистая история мастера (ну или релизной ветки) получалась сама собой, а в гите нужны костыли.