Ну если считать тех, кто "на удалённом серваке поправить 4 строки и всё", то да, больше. Если считать тех, кто используют редактор локально и "для всего", то neovim уже давно популярнее.
Плагины на Lua ещё как переписывают, т.к. хуже vimscript ничего не придумать. Но и последний прекрасно работает (кстати лучше чем в Vim), поэтому и старые плагины работают всегда или почти всегда.
А IDE вы видимо никогда не использовали, вот и не понимаете, о чём речь.
к счастью, у нас есть neovim, который благодаря простому но мощному API давно превзошел по функционалу и удобству не только Vim, но и любые IDE (справедливости ради IDE работают из коробки, но если вы - программист, то 200 строк на Lua вы точно осилите)
А как в месте возникновения ошибки получить request-id, user-id и т.д.? Те переменные, которые совсем не нужны в параметрах функции репозитория, но которые важны?
Не знаю. Я ошибку никогда не обрабатываю в месте возникновения, я передаю её наверх, прям самый верх, "где всё началось". А там обычно доступна вообще вся информация. А репозиторий в итоге занимается только своим делом, не знает, кто и как в нём смотрит.
Ну теперь понятно, спасибо. Те самые люди, которые называют Postgres "engine", они или некомпетентны, или ангажированы, вот и несут чушь)
Бэкапы и мониторинг точно были 10 лет назад, и всё это время только развивались. Средств тюнинга и автотюнинга уж точно не меньше чем для Oracle, есть даже на базе ИИ.
Разрабатывать ничего не нужно, "решение" уже готовое и рабочее.
Будем честными? Ну давайте, будем. Lighty уже был. Да и Апачи можно настроить аля nginx, потерять условных 90% функциональности (оно всё равно почти никому не нужно), но и получить условных 70-80% скорости nginx (да-да, так можно, просто почти никто не умеет). Так что альтернативы были. Просто nginx чуточку лучше.
Что до тэйка "многих критичных функций в Open Source просто нет, или даются с большими усилиями" я бы послушал поподробнее. Апачи обгнояет по функционалу известные мне проприетарные веб-серверы даже не намного, а "на круги".
У него 5 лет нормальной поддержки как теперь даже у бюджетников Самсы или нет? Если уже через 2,5 года на помойку (в первый месяц наверное лучше не покупать, какие-то досадные баги могут быть ещё не исправлены, да и цена завышена), то нет, не альтернатива.
У нас также есть фабричная функция NewSimpleEmployeeData, чтобы убедиться, что мы используем правильно сконструированный экземпляр SimpleEmployeeData не нужно писать фабричную функцию, но это хорошая практика, если вам нужно убедиться, что определенные поля в структуре правильно заполнены, прежде чем они будут использоваться. В этом случае необходимо убедиться, что карта сотрудников не равна нулю.
Тут плохо всё. Во-первых "ведущий эксперт OTUS" не понимает разницы между паттерном Фабрика и конструктором. Конкретный экземпляр конкретного типа возвращает второй, а не первый. Во-вторых в Go фабрики не нужны в принципе т.к. "единственный абстрактный тип" ((с) автор) в Go не используется так, как в Java или C#, откуда к нам фабрики и пришли.
type EmployeeData interface { AddEmployee(firstName, lastName string, dateHired time.Time) int GetEmployee(id int) (Employee, bool) AddManager(firstName, lastName string, dateHired time.Time, reports []int) int GetManager(id int) (Manager, bool) }
Гоферы так не пишут. Тут вам не Java, интерфейсы объявляются там, и только там, где используются. Это единственный способ нормально "разобрать" (decoupling) код и ослабить его связанность. Паттерны из Java делают Go-код абстрактным очень условно, по факту, он будет "прибит гвоздями". Ну посмотрите внимательно на этот интерфейс и его методы. Не может быть у вас второй реализации этой ерунды, она всегда будет одна. Уж в Go интерфейс для одной реализации не нужен точно.
Кстати сами методы просто ужасны. Они должны быть просто Add и Get. Empoyee и Manager или должны быть одним типом с полем bool внутри (оно будет определять кто менеджер) или разными типами, но в разных пакетах, тогда у нас будет Employee.Add(), Employee.Get(), Manager.Add(), Manager.Get()
Так и интерфейс лишь с двумя методами получит смысл.
Остальное и разбирать лень. А денежки лучше в gopl.io вложить, чем в такие курсы.
О чём на самом деле должна была быть статья: IT - это образ жизни такой, надо всё время что-то учить (теория), надо всё время практиковаться в чём-то. Не с 8 до 5. Не 5 дней в неделю. Не 7 месяцев, а всегда. В соблюдении этого принципа и есть отличие "вкатышков" от профи. Количество месяцев ничего не значит. И разумеется ВУЗы идут сюда же. Если очень повезёт - там научат CS, но обычно (по крайней мере в России) этого нет. Время потраченное в ВУЗе впустую - хороший показатель того, что человек может превозмогать долгосрочные проекты и достигать результата даже если смысл его усилий самому ему не очень понятен. И это объективно важно для многих работодателей. Но в остальном ВУЗ - о-о-о-очень длинные курсы.
Ну его. Посмотрите на Reddit тему с прогарами сокета. Да и скандал со сломанным USB/PCIe4 на AM4 ещё не забылся. Сам после Ryzen 2600 -> 5600x недавно перешёл на i5-13600k и более чем доволен.
Попробуйте посмореть на это с другой стороны и не выдавать нужду за добродетель. Кэш винды плохо помогает серверным нагрузкам, вот и приходится подменять его самодельным сурогатом. Линуксовый же кэш однозначно хорош для серверных нагрузок, и прикладные разработчики скорее всего реализуют его хуже. Другой вопрос в том, что из коробки этот дисковый кэш в Linux настроен неверно и тормозит многие нагрузки (например БД). Настроить его правильно с удовольствием поможет RH (разумеется за деньги). Ну или специалист, которого судя по настройкам *dirty* из статьи у разрабов нет.
Нет, ну что вы, эксперт Southbridge же явно написал про доступ к поддержке xD
Но Gorilla хоть хороша, на голову-две выше Gin. Который не оч хорош, но на 1000 голов выше Revel, Beego и Buffalo, которые просто ужасны. Последние 3 являются отличным примером того как НЕ писать на Go, от тех, кто "перебежал с другого языка", но освоил только синтаксис, притащив нерабочие паттерны из своего прошлого.
Зачем их запрещать? Для этого нужны внятные, объективные аргументы.
Аргументы почему это хорошо:
В Go есть идеоматические названия для переменных. Посмотрите код стандартной библиотеки и увидьте как называются в ней Reader и Writer например. Go-программист видит "w" и ожидает там writer. Видит i и ожидает счётчик. Конфиг сюда же.
Длинна имени переменной может являться подсказкой по области видимости переменной. Чем больше кода использует эту переменную, тем длиннее и описательнее должно быть её название. И наоборот, если она объявляется в сигнатуре и используется 2 раза внутри функции из 5 строк - одна буква это хороший выбор.
Имя this - очевидно плохая практика. Оно по определению зависит от контекста, который мы вынуждены удерживать во внимании. Это не даёт ничего, но усложняет mental model нашего кода, а мы этого не хотим. Мы хотим чётко представлять в уме всю реализацию задачи от и до, со всеми нюансами, это и отличает инженерию от "просто кодинга".
Спасибо. По ссылке есть внятные пруфы только про ldflags и 2016, но благодаря ей я нашёл обсуждение в google groups про strip. Хотя Дэйв Чейни и утверждает, что strip ломает бинари, остальные участники его опровергают. Будем пробовать.
Ну если считать тех, кто "на удалённом серваке поправить 4 строки и всё", то да, больше. Если считать тех, кто используют редактор локально и "для всего", то neovim уже давно популярнее.
Плагины на Lua ещё как переписывают, т.к. хуже vimscript ничего не придумать. Но и последний прекрасно работает (кстати лучше чем в Vim), поэтому и старые плагины работают всегда или почти всегда.
А IDE вы видимо никогда не использовали, вот и не понимаете, о чём речь.
Откуда взялась стабилизация звука? И что это вообще такое? Volume - это громкость, если про звук говорить.
Vim действительно не является ide
к счастью, у нас есть neovim, который благодаря простому но мощному API давно превзошел по функционалу и удобству не только Vim, но и любые IDE (справедливости ради IDE работают из коробки, но если вы - программист, то 200 строк на Lua вы точно осилите)
Не знаю. Я ошибку никогда не обрабатываю в месте возникновения, я передаю её наверх, прям самый верх, "где всё началось". А там обычно доступна вообще вся информация. А репозиторий в итоге занимается только своим делом, не знает, кто и как в нём смотрит.
Спасибо за статью. Начали за здравие, а потом...
"Чтобы создать ошибку со всей информацией..." контекст конечно не нужен. Нужно перечитывать вот это снова, и снова, и снова...
https://go.dev/blog/go1.13-errors
Ну теперь понятно, спасибо. Те самые люди, которые называют Postgres "engine", они или некомпетентны, или ангажированы, вот и несут чушь)
Бэкапы и мониторинг точно были 10 лет назад, и всё это время только развивались. Средств тюнинга и автотюнинга уж точно не меньше чем для Oracle, есть даже на базе ИИ.
Разрабатывать ничего не нужно, "решение" уже готовое и рабочее.
Нет, не странно. Если вы прочтёте 2-ое предложение hVostt, а потом ещё раз, то поймете, что я оспаривал тезис про софт 15-летней давности.
Что до Caddy и Traefik они open source т.ч. вы не соглашаетесь с hVostt, а наоборот, оспариваете его утверждение:
Будем честными? Ну давайте, будем. Lighty уже был. Да и Апачи можно настроить аля nginx, потерять условных 90% функциональности (оно всё равно почти никому не нужно), но и получить условных 70-80% скорости nginx (да-да, так можно, просто почти никто не умеет). Так что альтернативы были. Просто nginx чуточку лучше.
Что до тэйка "многих критичных функций в Open Source просто нет, или даются с большими усилиями" я бы послушал поподробнее. Апачи обгнояет по функционалу известные мне проприетарные веб-серверы даже не намного, а "на круги".
Не понимаю аналогии автомобиль vs двигатель. БД - это скорее багажник, что Oracle, что Postgres.
У него 5 лет нормальной поддержки как теперь даже у бюджетников Самсы или нет? Если уже через 2,5 года на помойку (в первый месяц наверное лучше не покупать, какие-то досадные баги могут быть ещё не исправлены, да и цена завышена), то нет, не альтернатива.
Тут плохо всё. Во-первых "ведущий эксперт OTUS" не понимает разницы между паттерном Фабрика и конструктором. Конкретный экземпляр конкретного типа возвращает второй, а не первый. Во-вторых в Go фабрики не нужны в принципе т.к. "единственный абстрактный тип" ((с) автор) в Go не используется так, как в Java или C#, откуда к нам фабрики и пришли.
Гоферы так не пишут. Тут вам не Java, интерфейсы объявляются там, и только там, где используются. Это единственный способ нормально "разобрать" (decoupling) код и ослабить его связанность. Паттерны из Java делают Go-код абстрактным очень условно, по факту, он будет "прибит гвоздями". Ну посмотрите внимательно на этот интерфейс и его методы. Не может быть у вас второй реализации этой ерунды, она всегда будет одна. Уж в Go интерфейс для одной реализации не нужен точно.
Кстати сами методы просто ужасны. Они должны быть просто Add и Get. Empoyee и Manager или должны быть одним типом с полем bool внутри (оно будет определять кто менеджер) или разными типами, но в разных пакетах, тогда у нас будет
Employee.Add(), Employee.Get(), Manager.Add(), Manager.Get()
Так и интерфейс лишь с двумя методами получит смысл.
Остальное и разбирать лень. А денежки лучше в gopl.io вложить, чем в такие курсы.
>>> PostrgeSQL не очень хорошо подходит для крупных банков и телекомов. Там очень специфический набор требований.
Есть какие-то аргументы? Работал в одном проекте с более чем 100 млн пользователей - Postgres справлялся играючи.
О чём на самом деле должна была быть статья: IT - это образ жизни такой, надо всё время что-то учить (теория), надо всё время практиковаться в чём-то. Не с 8 до 5. Не 5 дней в неделю. Не 7 месяцев, а всегда. В соблюдении этого принципа и есть отличие "вкатышков" от профи. Количество месяцев ничего не значит. И разумеется ВУЗы идут сюда же. Если очень повезёт - там научат CS, но обычно (по крайней мере в России) этого нет. Время потраченное в ВУЗе впустую - хороший показатель того, что человек может превозмогать долгосрочные проекты и достигать результата даже если смысл его усилий самому ему не очень понятен. И это объективно важно для многих работодателей. Но в остальном ВУЗ - о-о-о-очень длинные курсы.
Ну его. Посмотрите на Reddit тему с прогарами сокета. Да и скандал со сломанным USB/PCIe4 на AM4 ещё не забылся. Сам после Ryzen 2600 -> 5600x недавно перешёл на i5-13600k и более чем доволен.
Попробуйте посмореть на это с другой стороны и не выдавать нужду за добродетель. Кэш винды плохо помогает серверным нагрузкам, вот и приходится подменять его самодельным сурогатом. Линуксовый же кэш однозначно хорош для серверных нагрузок, и прикладные разработчики скорее всего реализуют его хуже.
Другой вопрос в том, что из коробки этот дисковый кэш в Linux настроен неверно и тормозит многие нагрузки (например БД). Настроить его правильно с удовольствием поможет RH (разумеется за деньги). Ну или специалист, которого судя по настройкам *dirty* из статьи у разрабов нет.
Нет, ну что вы, эксперт Southbridge же явно написал про доступ к поддержке xD
Но Gorilla хоть хороша, на голову-две выше Gin. Который не оч хорош, но на 1000 голов выше Revel, Beego и Buffalo, которые просто ужасны. Последние 3 являются отличным примером того как НЕ писать на Go, от тех, кто "перебежал с другого языка", но освоил только синтаксис, притащив нерабочие паттерны из своего прошлого.
Зачем их запрещать? Для этого нужны внятные, объективные аргументы.
Аргументы почему это хорошо:
В Go есть идеоматические названия для переменных. Посмотрите код стандартной библиотеки и увидьте как называются в ней Reader и Writer например. Go-программист видит "w" и ожидает там writer. Видит i и ожидает счётчик. Конфиг сюда же.
Длинна имени переменной может являться подсказкой по области видимости переменной. Чем больше кода использует эту переменную, тем длиннее и описательнее должно быть её название. И наоборот, если она объявляется в сигнатуре и используется 2 раза внутри функции из 5 строк - одна буква это хороший выбор.
Имя this - очевидно плохая практика. Оно по определению зависит от контекста, который мы вынуждены удерживать во внимании. Это не даёт ничего, но усложняет mental model нашего кода, а мы этого не хотим. Мы хотим чётко представлять в уме всю реализацию задачи от и до, со всеми нюансами, это и отличает инженерию от "просто кодинга".
почему не neovim с нативным LSP? это позволит избавиться от мерзонького COC (только подумайте, плагин для крошечного СИ-шного vim, требующий Node.js).
Спасибо. По ссылке есть внятные пруфы только про ldflags и 2016, но благодаря ей я нашёл обсуждение в google groups про strip. Хотя Дэйв Чейни и утверждает, что strip ломает бинари, остальные участники его опровергают. Будем пробовать.
Круто, хотелось бы верить. А какой-то пруф есть? Ну там issue resolved или что-то подобное. Не хотелось бы получить неожиданный segfault.