У меня такое чувство, что статьи об интерфейсах в Go выходят раз в полгода, и каждый раз бурность обсуждения показывает, что статье не удается быть ни убедительной, ни полной.
И дело тут не в авторах - они искренне стараются, а в экстремальной сложности темы. Не следует забывать, что именно эти правила осознанно не были добавлены на витрину Go Proverbs:
И для второго правила, Роб Пайк, соавтор языка Go, лично добавил:
I'm not a great fan of that one. It's subtle and tricky to explain compactly. And although popular, it's not often easy to apply well... It's very hard to be clear about where it applies, and it often doesn't.
Одной этой фразы должно было быть достаточно, чтобы насторожиться - легко не будет. Но мы все так же наивны и недооцениваем. Забавно.
Тот факт, что кто-то находит силы побеждать лень, мотивироваться и что-то делать - это всегда завидно и похвально.
Я перепробовал все, что есть, и прошел всю боль по пути с нуля до беглого разговорного B1 и медленного B2 (я не о том B1, который про "чекбоксы в тестах", а о том, когда берешь телефон и по плохой связи набираешь Флориду).
К сожалению, механическая зубрежка слов и фраз по словарям и таблицам не очень эффективна (по соотношению затраченных сил и долговременного результата). Да, это работает, да, это не вредит, да, все становится кратно лучше, если учитывать кривую забывания Эббингауза, но это все равно кратно хуже, чем нужно. Обязательно используйте эту технику только как дополнение к чему-то ещё.
Дело в том, что механизмы памяти очень плотно связаны с переживаемыми эмоциями. Для того, чтобы эффективно добираться до долговременной памяти, нужно обязательно предоставить возможность мозгу на этапе энкодинга (encoding) связать информацию с : юмором, удивлением, личными ассоциациями, дать информации персональную значимость или уловить её абсурдность, испытать "вау-эффект" от осознания полезности, испытать гордость от владения фактом, ощутить спокойствие от знания, предвкушение от будущего цитирования и так далее... Нужно хоть что-то, хоть минимальное, хоть крохотное!
Запомнить надолго 100 фраз "Френсис красит забор на ферме" почти невозможно, Эббингауз и интервальные повторения не помогут. А запомнить, например, 100 шуток Луи Си Кея, от которых вы ржете даже когда один в комнате - раз плюнуть (это я фигурально, но вы поняли идею).
То же самое происходит в фазе извлечения (retrieval). Без эмоционального подкрепления сложно сформировать рефлекторность использования. Фразы буквально нужно "вспоминать", а не "использовать". Или другими словами - мы язык будем "знать", но не "говорить на нем".
Будет обидно сжечь тонну сил на механическое заучивание одного языка и узнать, что твой сосед за это время успевает выучить три (мой опыт).
Так что используем приложухи и таблицы, но не перестаем применять и остальные важные техники! У вас все получится!
Искренне рад за всех, кто сумел. А тем, кому только предстоит, желаю удачи и дам совет, который мне когда-то был нужен и которого я не получил.
Мой стаж был примерно 20 лет, было очень тяжело и все такое, но в конечном итоге получилось. А потом пришел сюрприз, откуда не ждали: примерно за полтора-два года зрение рухнуло буквально в пол, стремительно.
Я уж не узнаю, было ли это жутким совпадением. Но что я знаю точно: пока я курил, каждые 40 минут я отрывался от монитора, шел на балкон, подолгу глядел вдаль, давая глазам полноценно отдыхать. А когда я бросил, по 24 часа в сутки не отрывал взгляд от монитора, который к тому же ещё и стоял неприлично близко.
Так что такой мой непрофессиональный совет: когда бросите, проследите, чтобы глаза и поясница получили недостающий им отдых. Я не медик и не знаю, как это работает, но чувствую, что опасность может быть реальна. На всякий случай.
Ну согласен, если прям аутентичности хочется, чтобы было "как раньше", то это есть. Но, с другой стороны, если они нашли время переделать меню и запихнуть рекламный баннер, то можно бы было уделить внимание и современному управлению.
Хотя, наверное, вы правы, и я бы не придирался, если бы оно у меня не висло раз в минуту (не удалось нормально осмотреться, обидно).
В любом случае Carter54 делает хорошую работу, могу только пожелать успехов.
Чисто из ностальгических соображений решил стартануть веб-версию. Технически - моё почтение, отрисовка воспринимается очень добротно. Но использовать игру "по назначению" почти невозможно: адаптация под современные реалии либо не была проведена, либо не удалась. Перемещение мыши отвечает за движение вперед (если она активирована), стрейф по-прежнему выполняется двумя кнопками и так далее...
Примерно раз в минуту игра зависает с ошибками:
Как, наверное, поругался бы Фабиен Санглард: "С классикой нужно обращаться бережнее!"
Я надеюсь, что в Телеграм оно работает лучше, иначе непонятно, как они за это решили просить деньги. Сыровато. Прям слякоть...
Прочитал вашу задачку - вроде интересная, но думаю, можно подобрать задачку получше. Позвольте пояснить (вдруг кому опыт пригодится)...
Дело в том, что "работать при зрителях" - это одна из самых стрессовых ситуаций в профессии. Даже если человек способен выдать решение или знает то, что мне нужно, далеко не факт, что я эту информацию смогу из него достать. Примерно у половины разработчиков тип личности такой, что при зрителях они буквально входят в ступор. Уж не знаю, как правильно этот эффект называют психологи - "социальная ингибиция" или просто "паническая атака", но факт в том, что нужен буквально "высший пилотаж", чтобы подобного человека раскрепостить. В рамках собеседования, скорее всего, просто не успеешь.
Поэтому со временем я ввел некоторые правила, которые помогают искать подходящие задачи. Одно из них звучит так:
Запрещено использовать текст задачи, в котором встречаются такие выражения, которые человек не мог вчера услышать "в IT-быту". То есть, запрещены: анаграмма, палиндром, сходящийся ряд, фулл-хаус, ход конем, интеграл, римские цифры, дискретность, инвариант, простые числа и так далее. Вы поняли идею...
Это не значит, что нужно запрещать все техническое. В активном словаре айтишника достаточно материала, чтобы работать. Например, следующие слова совершенно не вызывают проблем в тексте и нейтральны для состояния "пациента": стек, односвязный список, сортировка, массив, пара, вектор, равенство и т. д.
Я не имею в виду, что человек, скорее всего, "сложного" не знает - наоборот, скорее всего, все он знает. Но когда мы только знакомимся и занимаемся такой хрупкой работой, как оценка его аналитических способностей, способности к структурному мышлению, каждое лишнее слово может быть фатально. И мы просто не узнаем за отведенное время, кем же он был на самом деле.
PS: Кстати, если на какую-то позицию допустимо проводить собеседование без задач - лучше так и сделать. Вряд ли кто-то из нас заканчивал "пед". Мы с трудом понимаем, как именно это нужно делать, чтобы не навредить ни себе, ни испытуемому.
Использую в своей программе обучения ваши материалы. Хотел поблагодарить - отличная работа!
Но страничку с тестовыми базами данных можно было бы улучшить. Вместо маленькой ссылки внизу страницы о том, что вариантов баз несколько, лучше сделать яркую ремарку вверху.
Иначе следующий текст из книги вводит в заблуждение (вернее, неполон):
Как развернуть в вашем кластере PostgreSQL учебную базу данных... На сайте компании есть раздел, посвященный этой базе данных, найти его можно по ссылке https://postgrespro.ru/education/demodb.
Студенты открывают и, конечно же, качают последнюю (верхнюю, неправильную) версию. Никто не доскроливает до маленькой ссылки внизу. Ругаются 😉
А если вдруг кто-то ссылку и замечает, то все равно думает, что сделал что-то не так. Ведь вторая версия базы имеет настройку search_path, а соответствующая книга начинает давать примеры на запуск без его объяснения. Примеры не работают.
Отличный материал, но в паре мест перевод создает дополнительные трудности. Например, фраза ниже настолько выбила из колеи, что я с трудом вернулся обратно.
Размер функции в стековом кадре оказывается чуть больше 16 бит
При этом в английском варианте оказалось написано точнее, и читать было проще. Вот так:
This function ends up with a stack frame slightly larger than can be represented in 16 bits
Сейчас, когда я уже понимаю, что происходит, кажется, что и так пойдет, но, скорее всего, это только потому, что я уже и так понимаю о чем речь. А для тех, кто как и я, растерялся, оставлю тут подсказку, своими словами:
В архитектуре AArch64 все инструкции процессора занимают ровно 32 бита. Часть из этих 32 бит нужно потратить на обязательную служебную информацию, и свободных бит остается не так уж много.
А именно: в инструкции сложения ADD потрачено столько бит на служебные, что свободными для аргумента остаются только 12 бит. Значит, самая большая константа, которую мы можем прибавить, используя одну команду - это число от 0 до 4095 (то есть такое, которое влезает в 12 бит).
Если нужно прибавить число больше 4095, то компилятор должен использовать серию из нескольких команд. Таких серий существует несколько. Одна из таких серий - две последовательные команды ADD. Первая ADD складывает нижние 12 бит константы, вторая ADD - верхние 12 бит константы (для включения этого режима работы команды ADD, используется специальный бит из раздела служебных). Соответственно, эта серия из двух ADD дает возможность складывать уже 24 битные константы.
Очевидно, что две последовательные ADD уже не являются атомарной операцией, и если процессор прервать после первой ADD, то результат будет только "наполовину готов".
Для демонстрации проблемы авторы написали функцию, которая командой make([]byte, 65536) выделяет в стеке "как минимум" 65536 байт. То есть заставили компилятор генерировать ассемблерный код для добавления "как минимум" 65536 к регистру стека.
65536 - это очевидно больше чем 4095 и компилятору пришлось вместо одной ассемблерной команды использовать серию из нескольких. К сожалению, среди всех возможных вариантов компилятор выбрал неатомарный вариант из двух команд ADD.
Значит, полученный код нельзя прерывать, но именно это и сделал runtime Go при большом количестве повторных запусков - прервал выполнение между двумя ADD для сборки мусора и не смог справиться с "наполовину готовым" результатом сложения в регистре rSP. Программа упала.
Все это, конечно же, сказано в статье, но к сожалению, сказано так, что мой мозг "не кликнул". Так что оставлю мое упрощенное описание тут, вдруг кому-то пригодится.
Ясно, жаль. К сожалению, это та реальность, в которой нам предлагается существовать. Даже если мы ставим крохотный и легковесный редактор типа neovim (или кто там у нас поменьше), то рядом с ним все равно нужно будет скачать и запустить этого монстра на сотни мегабайт.
На сколько я знаю, сейчас только IDE от JetBrains имеют собственный анализатор кода для TS, но он тоже довольно прожорливый.
Так что если нужно работать с TS, выбора особо нет: либо так, либо вообще отключать анализатор.
Ещё не смотрел, что именно там происходит, но подозреваю, что данные процессы не родные для Zed. Это Language Servers, которые он запускает для полноценной работы с указанными вами файлами: html, css, ts...
Если открыть подробности процессов, то их аргументы запуска будут выглядеть примерно так:
node.exe …/tsserver.js
node.exe …/eslintServer.js
node.exe …/tailwindcss-language-server
Я не встречал сообщений о том, что команда Zed планировала вмешиваться в существующий порядок и переписывать имеющиеся LS на свой лад. Скорее всего, нужно быть готовым к тому, что большинство языков будет обрабатываться стандартными LS. И все те процессы, которые у нас работали в VS Code, будут использоваться и в Zed.
Но я все-таки надеюсь, что все несложные форматы, такие как dockerfile, env, разные конфиги и т. д. очень быстро получат родные wasm плагины и будут обрабатываться внутренним рантаймом. Нужно будет глянуть, как с этим обстоят дела сейчас.
Указатель — это значение, которое хранит адрес другой переменной.
Мне кажется, эта строка звучит слишком инородно для текста на русском. Переменная может что-то "хранить", значение может чем-то "являться" и т. д. Но фраза "значение что-то хранит" звучит слишком обывательски для обучающего материала. Лучше поискать вариант поточнее.
Кстати, мне обычно нравится следить за ходом мысли Дейва Чейни, он большой молодец, но конкретно этот его пост показался не очень удачным. Это тот редкий случай, когда вместо дословного перевода более выигрышно смотрелся бы "вольный перевод" или переработанная статья.
Я все же думаю, нет правильных или неправильных расцветок. Это одна из тех вещей, которые сугубо индивидуальны. Главное, чтобы расцветка работала для конкретного человека - этого достаточно.
Плюс задачи у разных людей разные. Кто-то хотел, как автор, чтобы акцентов было поменьше, но все они были поярче. А у кого-то задача была противоположная: он хотел, чтобы разные сущности были равноудалены друг от друга по внешнему виду, даже если это выглядит как новогодняя ёлка.
Для примера: в языке Go переменная пакета, константа, поле структуры, метод-значение и метод-выражение могут выглядеть похоже - xxxxx.Xxxxx. Кому-то это вполне комфортно, а кто-то использует цвет, чтобы добавить различий. Все по-своему правы.
Так что если вы чувствуете комфорт со своей подсветкой синтаксиса - ничего менять не нужно, вы все делаете правильно.
Внимательно прочитал ответ. Удивительно, насколько мы с вами разные - буквально из разных миров. Я решил, что ничего не буду добавлять к своему сообщению, и не буду оспаривать вашу позицию. Мы настолько разные, что в любом случае просто останемся при своем. Так тому и быть.
А вашему ответу, кстати, поставлю +1. Тот факт, что к моему резкому ранту вы смогли отнестись нейтрально, как минимум говорит о высоком профессионализме.
Я в каком-то параллельном мире живу. В моей выборке нет никого, кого можно было бы заставить использовать биометрию, даже силой (кроме случаев, когда мы сдаем её банку и государству и т. д.) Так странно… я наверное что-то упускаю. Это 42 пользователя FaceID что ли?
Казалось бы, лид лида должен понять. Но даже я не понимаю, каким образом описанное вами может работать, и не понимаю, как такие очевидные заблуждения оказались настолько живучими. Причем, что интересно, их нет в официальном Scrum Guide. Это инородный обвес, возрастом лет эдак 25, который каким-то образом прилип к процессу разработки и используется раз за разом не по назначению.
Вот прямо сейчас проверил наши "технологические карты": с момента, как разработчик ознакомился с заданием, должно пройти как минимум 5 важнейших этапов перед тем, как я могу попросить его оценить объем работ и его ответ будет иметь смысл.
Я понятия не имею, зачем спрашивать разработчика, который только что прочитал текст задания, о том, что он думает о его сложности и как долго он будет его делать. И тем более - зачем об этом спрашивать его коллегу.
Мне раньше было интересно: когда я нанимал человека из бигтеха, я спрашивал - "а что ты им отвечал на вопрос о стори-поинтах, в момент, когда очевидно, что ответа еще не существует?" Все как один: "Просто говорил разную чепуху, чтобы они отстали и успокоились. Главное - чтобы совпало с коллегой". Ужас…
Да, есть исключения. Если задача настолько примитивная, что текст задачи писать дольше, чем выполнять, то и оценивать её быстрее, чем описывать (это я, конечно, фигурально). Или если вы - R&D подразделение core-команды, у вас реально происходит настоящий коллективный брейншторм, и вам реально нужны относительные единицы измерения почти для всего и почти сразу.
Как эти вредные практики оказались такими живучими…
Даже их создатель (с которым я не согласен) использовал их как инструмент командного планирования. А планирование - это не "раздача задач", это особый вид деятельности, со своим регламентом, со своими артефактами, со своими требованиями к навыкам.
Нельзя просто так созвать митинг, показать команде текст задачи и спросить: “ну что, кто что думает, сколько кошек ставим?”
Я искренне надеюсь, что вы просто неудачно выразились, опустили важные моменты, и на самом деле не делаете "буквально" то, что описано в статье. Иначе - "да прибудет с вашими разработчиками сила", она им понадобится...
Не хочу комментировать по существу статьи - мы все ещё находимся в фазе "энтузиасты продолжают испытывать энтузиазм". Рано.
Но не могу удержаться, чтобы не подсветить вот какой забавный факт…
Подхожу к слабому разработчику, который не вылезает из общения с ИИ целый день. Говорю: "Покажи запрос". Он показывает две куцые строчки.
Спрашиваю: "Слушай, с тобой модель постоянно здоровается и хвалит за отлично поставленный вопрос. У тебя стоимость исходящего токена - 3, а входящего - 15. Предложение, в котором ты попросишь её перестать это делать, кратно короче и дешевле, чем каждый раз платить за вежливые обороты и тратить время на их прочтение. Почему ты этого не делаешь?" Он - опустил глаза, молчит…
И пришла мне вот какая нехорошая мысль: если специалист недостаточно хорош для своей позиции - не поможет уже ничего, ни ИИ, ни боженька за пазухой. Он просто слаб во всем, не готов к профессии.
Наверное, какое-то время можно пользоваться лайфхаком: спрашивать на собеседовании, использует ли разработчик ИИ. Они боятся сказать "нет", потому что это быстро вскрывается. А когда они скажут "да" - просить показать запрос. Поверьте, во многих случаях, это будет акт добровольной передачи вещественного доказательства того, что человек профнепригоден.
Это конечно же шутка, но есть в этой шутке что-то не шуточное, и даже пугающее :)
Полностью поддерживаю. Несколько раз сталкивались с JSON-RPC (работали со stratum протоколом и межсервисным велосипедом), остались только самые положительные впечатления.
Кстати, такое забавное наблюдение: JSON-RPC реализованный слабым разработчиком, намного менее проблемный и более приятный в работе, чем RESTful протокол, реализованный моим лучшим разработчиком.
И побочный эффект: если какая-то команда попробовала оба варианта - потом всегда будет напоминать и просить JSON-RPC, даже если ТЗ предполагает что-то другое.
Спросите любого архитектора - ему, по большому счету, плевать, какие части HTTP протокола его заставят использовать или не использовать. Его задача - управлять сложностью! Он может что-то любить или не любить, но проблем от HTTP он не почувствует. Не стоит себе льстить: HTTP протокол - это не теория струн, он бесконечно проще того, чем архитектор обычно занимается.
Но вот что архитектора действительно волнует - это границы и межкомпонентное взаимодействие. Именно здесь чаще всего рождается лишняя сложность. И если вы предложите разрушить абстракции и аморфно склеить какие-то слои системы, опытный архитектор точно спросит: “Зачем?”. Ведь он знает, что плата высока, и будет безумием добровольно ее заплатить, не получив ничего взамен.
Архитектору плевать, когда люди обсуждают, чему именно они хотят разрешить протечь из транспортного уровня в прикладной уровень (логический уровень взаимодействия систем). И плевать, какой аббревиатуре это будет соответствовать. Важен только сам факт того, что граница нарушена.
Вот вы, например, пытались-пытались вырулить, по крохам собирали участки, где можно уменьшить сложность до удобоваримой. Дописали до раздела обработки ошибок и…
200 OK, на мой взгляд, это как-то очень скучно и сухо… как же промежуточные системы
… и все - транспортный уровень всеми своими кишками протек в приложение. “Скучно ему, видите ли”. Архитектор полностью перепишет эти два слоя, уберёт границу из кода, блокеры из диздока и повысит смету проекта. Какая теперь разница, что именно протекло - можете тащить и все остальное. Урон - нанесен, код - готов, банкет - оплачен.
И проблема с REST именно в этом - вас миллионы. У кого-то протекли коды ошибок, у кого-то глаголы, у кого-то управление кэшами; кто-то тащит родные возможности по управлению идемпотентностью; кто-то боится не быть готовым к мифическим network middleware; кто-то переносит части тела в URL, чтобы найти их в логах; у кого-то протекла аутентификация; кто-то не может работать, если стандартная панель браузера не парсит трафик; кто-то тащит все, для чего есть подсветка синтаксиса в .http файлах; кто-то привык к популярному фреймворку; кто-то не знает свой CDN и готовится ко всему на свете...
И нет никакого смысла писать статьи о том, кто из них более неправ либо менее неправ. Или о том, как нужно изменить аббревиатуру, чтобы было не стыдно.
Как поэтично говорит один из моих знакомых архитекторов: “Если оборона пала, то неважно, что я буду писать в диздок - все равно весь хлеб будет украден, а все девки изнасилованы - это у варваров в крови”.
Спросите, что же делать? Можно ли вообще использовать REST или что-то на него похожее? Конечно, но! Только если это является реальным требованием в техническом задании проекта, с обоснованием в виде твердого намерения использовать те свойства и возможности, которые он предоставляет, и с финансированием последствий. А не мифическое: “а вдруг через 5 лет мы захотим мигать лампочкой в коридоре при неправильном пароле - без изменений в коде”.
Намек начинающим: не переживайте, если вам кажется, что с REST что-то не то, но все вокруг ведут себя как слепые - вы не одиноки, с вами все в порядке. Просто некоторые темы ковырять не принято, чтобы экономить ресурсы, раз уж непоправимый урон уже нанесен. Работайте с тем, что есть, пока не дорастете до уровня принятия решений.
У меня такое чувство, что статьи об интерфейсах в Go выходят раз в полгода, и каждый раз бурность обсуждения показывает, что статье не удается быть ни убедительной, ни полной.
И дело тут не в авторах - они искренне стараются, а в экстремальной сложности темы. Не следует забывать, что именно эти правила осознанно не были добавлены на витрину Go Proverbs:
Interfaces belong to the consumer (отсутствует)
Accept interfaces, return concrete types (отсутствует)
И для второго правила, Роб Пайк, соавтор языка Go, лично добавил:
Одной этой фразы должно было быть достаточно, чтобы насторожиться - легко не будет. Но мы все так же наивны и недооцениваем. Забавно.
Тот факт, что кто-то находит силы побеждать лень, мотивироваться и что-то делать - это всегда завидно и похвально.
Я перепробовал все, что есть, и прошел всю боль по пути с нуля до беглого разговорного B1 и медленного B2 (я не о том B1, который про "чекбоксы в тестах", а о том, когда берешь телефон и по плохой связи набираешь Флориду).
К сожалению, механическая зубрежка слов и фраз по словарям и таблицам не очень эффективна (по соотношению затраченных сил и долговременного результата). Да, это работает, да, это не вредит, да, все становится кратно лучше, если учитывать кривую забывания Эббингауза, но это все равно кратно хуже, чем нужно. Обязательно используйте эту технику только как дополнение к чему-то ещё.
Дело в том, что механизмы памяти очень плотно связаны с переживаемыми эмоциями. Для того, чтобы эффективно добираться до долговременной памяти, нужно обязательно предоставить возможность мозгу на этапе энкодинга (encoding) связать информацию с : юмором, удивлением, личными ассоциациями, дать информации персональную значимость или уловить её абсурдность, испытать "вау-эффект" от осознания полезности, испытать гордость от владения фактом, ощутить спокойствие от знания, предвкушение от будущего цитирования и так далее... Нужно хоть что-то, хоть минимальное, хоть крохотное!
Запомнить надолго 100 фраз "Френсис красит забор на ферме" почти невозможно, Эббингауз и интервальные повторения не помогут. А запомнить, например, 100 шуток Луи Си Кея, от которых вы ржете даже когда один в комнате - раз плюнуть (это я фигурально, но вы поняли идею).
То же самое происходит в фазе извлечения (retrieval). Без эмоционального подкрепления сложно сформировать рефлекторность использования. Фразы буквально нужно "вспоминать", а не "использовать". Или другими словами - мы язык будем "знать", но не "говорить на нем".
Будет обидно сжечь тонну сил на механическое заучивание одного языка и узнать, что твой сосед за это время успевает выучить три (мой опыт).
Так что используем приложухи и таблицы, но не перестаем применять и остальные важные техники! У вас все получится!
Искренне рад за всех, кто сумел. А тем, кому только предстоит, желаю удачи и дам совет, который мне когда-то был нужен и которого я не получил.
Мой стаж был примерно 20 лет, было очень тяжело и все такое, но в конечном итоге получилось. А потом пришел сюрприз, откуда не ждали: примерно за полтора-два года зрение рухнуло буквально в пол, стремительно.
Я уж не узнаю, было ли это жутким совпадением. Но что я знаю точно: пока я курил, каждые 40 минут я отрывался от монитора, шел на балкон, подолгу глядел вдаль, давая глазам полноценно отдыхать. А когда я бросил, по 24 часа в сутки не отрывал взгляд от монитора, который к тому же ещё и стоял неприлично близко.
Так что такой мой непрофессиональный совет: когда бросите, проследите, чтобы глаза и поясница получили недостающий им отдых. Я не медик и не знаю, как это работает, но чувствую, что опасность может быть реальна. На всякий случай.
Ну согласен, если прям аутентичности хочется, чтобы было "как раньше", то это есть. Но, с другой стороны, если они нашли время переделать меню и запихнуть рекламный баннер, то можно бы было уделить внимание и современному управлению.
Хотя, наверное, вы правы, и я бы не придирался, если бы оно у меня не висло раз в минуту (не удалось нормально осмотреться, обидно).
В любом случае Carter54 делает хорошую работу, могу только пожелать успехов.
Чисто из ностальгических соображений решил стартануть веб-версию. Технически - моё почтение, отрисовка воспринимается очень добротно. Но использовать игру "по назначению" почти невозможно: адаптация под современные реалии либо не была проведена, либо не удалась. Перемещение мыши отвечает за движение вперед (если она активирована), стрейф по-прежнему выполняется двумя кнопками и так далее...
Примерно раз в минуту игра зависает с ошибками:
Как, наверное, поругался бы Фабиен Санглард: "С классикой нужно обращаться бережнее!"
Я надеюсь, что в Телеграм оно работает лучше, иначе непонятно, как они за это решили просить деньги. Сыровато. Прям слякоть...
Понял вас, спасибо за пояснение. Тогда мой комментарий нерелевантен.
Но пусть будет, раз уж я его накатал, может кому мысль пригодится.
Прочитал вашу задачку - вроде интересная, но думаю, можно подобрать задачку получше. Позвольте пояснить (вдруг кому опыт пригодится)...
Дело в том, что "работать при зрителях" - это одна из самых стрессовых ситуаций в профессии. Даже если человек способен выдать решение или знает то, что мне нужно, далеко не факт, что я эту информацию смогу из него достать. Примерно у половины разработчиков тип личности такой, что при зрителях они буквально входят в ступор. Уж не знаю, как правильно этот эффект называют психологи - "социальная ингибиция" или просто "паническая атака", но факт в том, что нужен буквально "высший пилотаж", чтобы подобного человека раскрепостить. В рамках собеседования, скорее всего, просто не успеешь.
Поэтому со временем я ввел некоторые правила, которые помогают искать подходящие задачи. Одно из них звучит так:
Это не значит, что нужно запрещать все техническое. В активном словаре айтишника достаточно материала, чтобы работать. Например, следующие слова совершенно не вызывают проблем в тексте и нейтральны для состояния "пациента": стек, односвязный список, сортировка, массив, пара, вектор, равенство и т. д.
Я не имею в виду, что человек, скорее всего, "сложного" не знает - наоборот, скорее всего, все он знает. Но когда мы только знакомимся и занимаемся такой хрупкой работой, как оценка его аналитических способностей, способности к структурному мышлению, каждое лишнее слово может быть фатально. И мы просто не узнаем за отведенное время, кем же он был на самом деле.
PS: Кстати, если на какую-то позицию допустимо проводить собеседование без задач - лучше так и сделать. Вряд ли кто-то из нас заканчивал "пед". Мы с трудом понимаем, как именно это нужно делать, чтобы не навредить ни себе, ни испытуемому.
Использую в своей программе обучения ваши материалы. Хотел поблагодарить - отличная работа!
Но страничку с тестовыми базами данных можно было бы улучшить. Вместо маленькой ссылки внизу страницы о том, что вариантов баз несколько, лучше сделать яркую ремарку вверху.
Иначе следующий текст из книги вводит в заблуждение (вернее, неполон):
Студенты открывают и, конечно же, качают последнюю (верхнюю, неправильную) версию. Никто не доскроливает до маленькой ссылки внизу. Ругаются 😉
А если вдруг кто-то ссылку и замечает, то все равно думает, что сделал что-то не так. Ведь вторая версия базы имеет настройку
search_path, а соответствующая книга начинает давать примеры на запуск без его объяснения. Примеры не работают.Думаю эту ситуацию можно было бы улучшить.
В любом случае огромное спасибо!
Отличный материал, но в паре мест перевод создает дополнительные трудности. Например, фраза ниже настолько выбила из колеи, что я с трудом вернулся обратно.
При этом в английском варианте оказалось написано точнее, и читать было проще. Вот так:
Сейчас, когда я уже понимаю, что происходит, кажется, что и так пойдет, но, скорее всего, это только потому, что я уже и так понимаю о чем речь. А для тех, кто как и я, растерялся, оставлю тут подсказку, своими словами:
Все это, конечно же, сказано в статье, но к сожалению, сказано так, что мой мозг "не кликнул". Так что оставлю мое упрощенное описание тут, вдруг кому-то пригодится.
Ясно, жаль. К сожалению, это та реальность, в которой нам предлагается существовать. Даже если мы ставим крохотный и легковесный редактор типа neovim (или кто там у нас поменьше), то рядом с ним все равно нужно будет скачать и запустить этого монстра на сотни мегабайт.
На сколько я знаю, сейчас только IDE от JetBrains имеют собственный анализатор кода для TS, но он тоже довольно прожорливый.
Так что если нужно работать с TS, выбора особо нет: либо так, либо вообще отключать анализатор.
Ещё не смотрел, что именно там происходит, но подозреваю, что данные процессы не родные для Zed. Это Language Servers, которые он запускает для полноценной работы с указанными вами файлами: html, css, ts...
Если открыть подробности процессов, то их аргументы запуска будут выглядеть примерно так:
node.exe …/tsserver.js
node.exe …/eslintServer.js
node.exe …/tailwindcss-language-server
Я не встречал сообщений о том, что команда Zed планировала вмешиваться в существующий порядок и переписывать имеющиеся LS на свой лад. Скорее всего, нужно быть готовым к тому, что большинство языков будет обрабатываться стандартными LS. И все те процессы, которые у нас работали в VS Code, будут использоваться и в Zed.
Но я все-таки надеюсь, что все несложные форматы, такие как dockerfile, env, разные конфиги и т. д. очень быстро получат родные wasm плагины и будут обрабатываться внутренним рантаймом. Нужно будет глянуть, как с этим обстоят дела сейчас.
Мне кажется, эта строка звучит слишком инородно для текста на русском. Переменная может что-то "хранить", значение может чем-то "являться" и т. д. Но фраза "значение что-то хранит" звучит слишком обывательски для обучающего материала. Лучше поискать вариант поточнее.
Кстати, мне обычно нравится следить за ходом мысли Дейва Чейни, он большой молодец, но конкретно этот его пост показался не очень удачным. Это тот редкий случай, когда вместо дословного перевода более выигрышно смотрелся бы "вольный перевод" или переработанная статья.
Я все же думаю, нет правильных или неправильных расцветок. Это одна из тех вещей, которые сугубо индивидуальны. Главное, чтобы расцветка работала для конкретного человека - этого достаточно.
Плюс задачи у разных людей разные. Кто-то хотел, как автор, чтобы акцентов было поменьше, но все они были поярче. А у кого-то задача была противоположная: он хотел, чтобы разные сущности были равноудалены друг от друга по внешнему виду, даже если это выглядит как новогодняя ёлка.
Для примера: в языке Go переменная пакета, константа, поле структуры, метод-значение и метод-выражение могут выглядеть похоже -
xxxxx.Xxxxx. Кому-то это вполне комфортно, а кто-то использует цвет, чтобы добавить различий. Все по-своему правы.Так что если вы чувствуете комфорт со своей подсветкой синтаксиса - ничего менять не нужно, вы все делаете правильно.
Внимательно прочитал ответ. Удивительно, насколько мы с вами разные - буквально из разных миров. Я решил, что ничего не буду добавлять к своему сообщению, и не буду оспаривать вашу позицию. Мы настолько разные, что в любом случае просто останемся при своем. Так тому и быть.
А вашему ответу, кстати, поставлю +1. Тот факт, что к моему резкому ранту вы смогли отнестись нейтрально, как минимум говорит о высоком профессионализме.
Если я испытываю жажду - пью...
Если я испытываю голод - ем...
Если я испытываю недостаток квалификации - учусь...
Если вам нужна была пояснительная бригада, чтобы понять такую простую мысль, то это лишь придает моей абсурдной истории выше дополнительный блеск.
А если это была попытка троллинга - оно того не стоило.
Я в каком-то параллельном мире живу. В моей выборке нет никого, кого можно было бы заставить использовать биометрию, даже силой (кроме случаев, когда мы сдаем её банку и государству и т. д.) Так странно… я наверное что-то упускаю. Это 42 пользователя FaceID что ли?
Казалось бы, лид лида должен понять. Но даже я не понимаю, каким образом описанное вами может работать, и не понимаю, как такие очевидные заблуждения оказались настолько живучими. Причем, что интересно, их нет в официальном Scrum Guide. Это инородный обвес, возрастом лет эдак 25, который каким-то образом прилип к процессу разработки и используется раз за разом не по назначению.
Вот прямо сейчас проверил наши "технологические карты": с момента, как разработчик ознакомился с заданием, должно пройти как минимум 5 важнейших этапов перед тем, как я могу попросить его оценить объем работ и его ответ будет иметь смысл.
Я понятия не имею, зачем спрашивать разработчика, который только что прочитал текст задания, о том, что он думает о его сложности и как долго он будет его делать. И тем более - зачем об этом спрашивать его коллегу.
Мне раньше было интересно: когда я нанимал человека из бигтеха, я спрашивал - "а что ты им отвечал на вопрос о стори-поинтах, в момент, когда очевидно, что ответа еще не существует?" Все как один: "Просто говорил разную чепуху, чтобы они отстали и успокоились. Главное - чтобы совпало с коллегой". Ужас…
Да, есть исключения. Если задача настолько примитивная, что текст задачи писать дольше, чем выполнять, то и оценивать её быстрее, чем описывать (это я, конечно, фигурально). Или если вы - R&D подразделение core-команды, у вас реально происходит настоящий коллективный брейншторм, и вам реально нужны относительные единицы измерения почти для всего и почти сразу.
Как эти вредные практики оказались такими живучими…
Даже их создатель (с которым я не согласен) использовал их как инструмент командного планирования. А планирование - это не "раздача задач", это особый вид деятельности, со своим регламентом, со своими артефактами, со своими требованиями к навыкам.
Нельзя просто так созвать митинг, показать команде текст задачи и спросить: “ну что, кто что думает, сколько кошек ставим?”
Я искренне надеюсь, что вы просто неудачно выразились, опустили важные моменты, и на самом деле не делаете "буквально" то, что описано в статье. Иначе - "да прибудет с вашими разработчиками сила", она им понадобится...
Не хочу комментировать по существу статьи - мы все ещё находимся в фазе "энтузиасты продолжают испытывать энтузиазм". Рано.
Но не могу удержаться, чтобы не подсветить вот какой забавный факт…
Подхожу к слабому разработчику, который не вылезает из общения с ИИ целый день. Говорю: "Покажи запрос". Он показывает две куцые строчки.
Спрашиваю: "Слушай, с тобой модель постоянно здоровается и хвалит за отлично поставленный вопрос. У тебя стоимость исходящего токена - 3, а входящего - 15. Предложение, в котором ты попросишь её перестать это делать, кратно короче и дешевле, чем каждый раз платить за вежливые обороты и тратить время на их прочтение. Почему ты этого не делаешь?" Он - опустил глаза, молчит…
И пришла мне вот какая нехорошая мысль: если специалист недостаточно хорош для своей позиции - не поможет уже ничего, ни ИИ, ни боженька за пазухой. Он просто слаб во всем, не готов к профессии.
Наверное, какое-то время можно пользоваться лайфхаком: спрашивать на собеседовании, использует ли разработчик ИИ. Они боятся сказать "нет", потому что это быстро вскрывается. А когда они скажут "да" - просить показать запрос. Поверьте, во многих случаях, это будет акт добровольной передачи вещественного доказательства того, что человек профнепригоден.
Это конечно же шутка, но есть в этой шутке что-то не шуточное, и даже пугающее :)
Полностью поддерживаю. Несколько раз сталкивались с JSON-RPC (работали со stratum протоколом и межсервисным велосипедом), остались только самые положительные впечатления.
Кстати, такое забавное наблюдение: JSON-RPC реализованный слабым разработчиком, намного менее проблемный и более приятный в работе, чем RESTful протокол, реализованный моим лучшим разработчиком.
И побочный эффект: если какая-то команда попробовала оба варианта - потом всегда будет напоминать и просить JSON-RPC, даже если ТЗ предполагает что-то другое.
Спросите любого архитектора - ему, по большому счету, плевать, какие части HTTP протокола его заставят использовать или не использовать. Его задача - управлять сложностью! Он может что-то любить или не любить, но проблем от HTTP он не почувствует. Не стоит себе льстить: HTTP протокол - это не теория струн, он бесконечно проще того, чем архитектор обычно занимается.
Но вот что архитектора действительно волнует - это границы и межкомпонентное взаимодействие. Именно здесь чаще всего рождается лишняя сложность. И если вы предложите разрушить абстракции и аморфно склеить какие-то слои системы, опытный архитектор точно спросит: “Зачем?”. Ведь он знает, что плата высока, и будет безумием добровольно ее заплатить, не получив ничего взамен.
Архитектору плевать, когда люди обсуждают, чему именно они хотят разрешить протечь из транспортного уровня в прикладной уровень (логический уровень взаимодействия систем). И плевать, какой аббревиатуре это будет соответствовать. Важен только сам факт того, что граница нарушена.
Вот вы, например, пытались-пытались вырулить, по крохам собирали участки, где можно уменьшить сложность до удобоваримой. Дописали до раздела обработки ошибок и…
… и все - транспортный уровень всеми своими кишками протек в приложение. “Скучно ему, видите ли”. Архитектор полностью перепишет эти два слоя, уберёт границу из кода, блокеры из диздока и повысит смету проекта. Какая теперь разница, что именно протекло - можете тащить и все остальное. Урон - нанесен, код - готов, банкет - оплачен.
И проблема с REST именно в этом - вас миллионы. У кого-то протекли коды ошибок, у кого-то глаголы, у кого-то управление кэшами; кто-то тащит родные возможности по управлению идемпотентностью; кто-то боится не быть готовым к мифическим network middleware; кто-то переносит части тела в URL, чтобы найти их в логах; у кого-то протекла аутентификация; кто-то не может работать, если стандартная панель браузера не парсит трафик; кто-то тащит все, для чего есть подсветка синтаксиса в .http файлах; кто-то привык к популярному фреймворку; кто-то не знает свой CDN и готовится ко всему на свете...
И нет никакого смысла писать статьи о том, кто из них более неправ либо менее неправ. Или о том, как нужно изменить аббревиатуру, чтобы было не стыдно.
Как поэтично говорит один из моих знакомых архитекторов: “Если оборона пала, то неважно, что я буду писать в диздок - все равно весь хлеб будет украден, а все девки изнасилованы - это у варваров в крови”.
Спросите, что же делать? Можно ли вообще использовать REST или что-то на него похожее? Конечно, но! Только если это является реальным требованием в техническом задании проекта, с обоснованием в виде твердого намерения использовать те свойства и возможности, которые он предоставляет, и с финансированием последствий. А не мифическое: “а вдруг через 5 лет мы захотим мигать лампочкой в коридоре при неправильном пароле - без изменений в коде”.
Намек начинающим: не переживайте, если вам кажется, что с REST что-то не то, но все вокруг ведут себя как слепые - вы не одиноки, с вами все в порядке. Просто некоторые темы ковырять не принято, чтобы экономить ресурсы, раз уж непоправимый урон уже нанесен. Работайте с тем, что есть, пока не дорастете до уровня принятия решений.