Если вас напрягает привязка к Google Firebase вы можете попробовать присмотреться к неполной альтернативе в виде Supabase (GitHub: https://github.com/supabase/supabase), которое является Open Source решением и большинство функционала которого базируется поверх уже знакомого многим PostgreSQL.
С учетом того, какие нередко обновления идут, не удивлюсь если вскоре успешность установки этих обновлений будет зависеть от прохождения игры, типа "Не прошел игру - получай проблемы с гибернацией." Да и техподдержке будет что ответить: "У вас проблемы с тачскрином? Попробуйте перезагрузить компьютер пройти финального босса при обновлении..."
Обратите внимание пожалуйста на разницу этих двух примеров:
import Bar from './bar';
и
import {Foo as Bar} from './bar';
Несколько моментов:
В первом случае импортируется "что-то", что далее будет именоваться как Bar и нет никаких гарантий, что это будет именно класс Foo. Во втором случае, вы явно импортируете конкретно класс Foo и при помощи оператора as четко даете понять ревьюверу, что вам необходим именно класс Foo, но в данном модуле он будет именоваться как класс Bar.
Далее, если взглянуть на первый вариант, будет ли очевидно без помощи IDE, что для того, чтобы понять, что такое Bar и какое у него назначение, вам нужно будет в справке прочитать раздел про класс Foo модуля bar. Во втором случае, вcе гораздо очевидней (класс Foo, модуль bar);
В JS, где с контролем типов и так все грустно (привет нарастающей популярности TypeScript), встроенная проверка того, что импортируется именно класс Foo будет не лишней. Если кто-нибудь случайно или специально сделает какой-то другой класс экспортируемым по умолчанию, то во втором случае вы сразу получите ошибку импорта. А вот в первом случае вы получите ошибку об отсутствии в объекте каких-то методов или свойств и не сразу догадаетесь, что это связано именно с некорректным импортом.
Код обычно читают намного чаще, чем пишут, поэтому чем очевидней код при чтении, тем лучше. В любом случае, стоит придерживаться соглашений по стилю кода (в т.ч. по экспортам/импортам), которые уже приняты в проекте.
Пример поведения, который не всегда является желанным:
bar.ts :
export default class Foo { ... }
custom-module.ts:
import Foo from './bar'; // Валидно.
import Bar from './bar'; // Также валидно.
Потом при ревью, отладке и пр., в голове приходится держать, что Foo === Bar, что не всегда очевидно и может приводить к неприятным неожиданностям в коде.
Что касается "верблюжий/змеиный регистр" — такая формулировка нередко встречается в литературе. Термин "нотация" лучше (верблюжья/змеиная нотация), но такой термин нечасто используется по отношению к именованию файлов. Еще вариантом является просто слово "стиль", оно универсально и такой вариант использовался переводчиком Google JavaScript Style Guide.
В таком случае, оригинальную фразу вполне можно перевести так:
Импорты пространств имен модулей пишутся в стиле lowerCamelCase в то время как файлы именуются в стиле snake_case, что означает, что корректные импорты не будут совпадать по стилю написания с именами файлов.
Параметры типа
Вы подметили один из проблемных в плане перевода терминов.
Проблема в том, что слова "типовое/типовые" многими воспринимается как синоним "типичное" или "стандартное" (пример повседневной фразы: "типовое решение"), особенно среди новичков и тех, кто незнаком с дженериками. Такое слово всегда должно писаться с явным ударением: "ти́повые параметры".
Вариант в виде "Обобщенный тип" часто представляется просто как "обобщение или дженерик", а термин "generic" в руководстве уже используется.
В итоге вариант "параметры типа" остался как компромисный, тем более про них в руководстве совсем немного описано. Наверное для таких спорных по наименованию терминологий, в тексте перевода было бы правильней указывать сноски-ссылки на термин в вики, MDN и пр., чтобы развеять возможные неточности.
А так, благодарю вас за уделенное внимание и полезные замечания. Если у вас в дальнейшем появятся предложения или замечания по тексту, как вариант, вы можете создать issue, поскольку тут ветка комментариев может уйти далеко от темы автора.
Данный перевод, как ни странно делался вручную, шаг за шагом. О пояснении причин и особенностей перевода опубликована целая статья.
Т.к. это именно руководство, т.е. документ, то при переводе важно было соблюдать точность, поэтому перевод делался буквальным, а не адаптированным и поэтому текст может читаться тяжело, о чем даже явно было описано в статье. При адаптированном переводе есть огромная вероятность внести отсебятину, которая может внести смысловую ошибку, что для руководства недопустимо. Оригинал также читается местами тяжело, с чем столкнулся также и переводчик Google JavaScript Style Guide.
Помимо этого, была необходимость подогнать текст перевода в соответствии с терминами «MUST», «SHOULD», «MAY» с учетом RFC. Как раз в недавнем обновлении оригинала уделили много внимания выделению этих терминов, что сразу же было учтено и в обновлении перевода.
В статье я специально выделил момент с автоматическими переводчиками, поскольку они часто и «MUST» и «SHOULD» переводят как «ДОЛЖЕН», а данное слово в русском языке несет обязательный оттенок. Поэтому SHOULD был в документе перефразирован под RECOMMENDED, что не нарушает RFC2119, но позволяет явно разделить по смыслу ключевые слова на три группы "должен", "рекомендуется", "возможно" (хотя сейчас я думаю, что более подошло бы слово "допустимо").
Также в оригинале есть ошибки, которые учтены в переводе и описаны в примечании. Помимо этого, в перевод добавлено множество уточнений и скорректировано форматирование.
То что пунктуация может хромать - это вполне возможно, поскольку когда приходится шаг за шагом переводить подобный текст - в глазах это уже мылится. Если есть предложение, как что-то можно сделать более читаемым, но с обязательным сохранением всех деталей оригинальной фразы - рад буду учесть. В любом случае проект открыт и вы можете предложить пожелания или правки.
По возможности, уточните пожалуйста, где именно данный перевод некорректен?
Тут недавно на Хабре, как раз под эту тему недавно была опубликована статья (перевод) "Хватит ссылаться на TIOBE", где обсуждалась проблема использования TIOBE как рейтинга. В своем комментарии к той статье я также упомянул и проблемы IEEE Spectrum (которые в чем то общие с TIOBE). Так вот, метод расчет рейтинга IEEE Spetrum описан у них на странице. Согласно этой странице, они используют данные из 8-ми источников (CareerBuilder, GitHub, Google, Hacker News, IEEE, Reddit, Stack Overflow, Twitter). Стоит обратить внимание, что к рейтингу они приплетают careerbuilder.com - в котором в основном представлены вакансии из США, а из поисковиков они используют только Google и выборка там идет (как и у TIOBE) на основе подсчета количества поисковых запросов вида `+" programming"`. Лично я считаю, что такой показатель может также указывать на отвратительное качество документации языка, раз постоянно гуглить приходится. Или вот пример из того комментария:
... Или пример с TypeScript, который в итоге транспилируется в JavaScript. и если потом вылазят какие-то проблемы, вы можете гугля проблему неявно добавить +1 к рейтингу JavaScript. Тоже самое касается и WASM, ибо для взаимодействия с браузером всеравно нужен JavaScript. Является ли это корректным показателем популярности JavaScript - спорно.
Этот пример также прекрасно подходит в случае с SQL и пр.
Лично я считаю, что и TIOBE и IEEE Spectrum и пр. совсем не отражают истинную популярность языков программмирования. Но зато данными этих рейтингов очень удобно манипулировать, например, в спорах или в рекламе всяких курсов и пр. Из того же комментария:
Вспомнил, что видел какую-то рекламу каких-то типичных курсов, где про один из рекламируемых языков было написано, что "...язык X является 1-м по популярности согласно рейтингу Y, поэтому вы легко найдете работу..." и рядом с этой рекламой, была другая реклама от этой же конторы, где было написано тоже самое про другой язык, только там был упомянут уже другой рейтинг. В общем - манипуляция в чистом виде.
P.S. Простите что ссылаюсь на свой же комментарий из другой статьи - не хотелось совсем уж копипастить.
Спасибо за статью. Сам после того, как не раз столкнулся с холиварами с этими рейтингами, рассмотрел их метрики более внимательно и пришел к выводу, что по факту они не отражают истинную популярность языков программирования, о чем я как-то написал год назад статью у себя на сайте (не реклама - статья чисто по теме).
Если вкратце, возьмем например "индекс TIOBE", у которых индекс рассчитывается на основе подсчета количества поисковых запросов вида `+"<language> programming"` (https://www.tiobe.com/tiobe-index/programming-languages-definition/). Лично я считаю, что такой показатель может также указывать на отвратительное качество документации языка, раз постоянно гуглить приходится. Например, у того же PHP очень неплохая документация расположена на официальном сайте, что снижает уровень излишнего гугления и соответственно рейтинга.
Или пример с TypeScript, который в итоге транспилируется в JavaScript. и если потом вылазят какие-то проблемы, вы можете гугля проблему неявно добавить +1 к рейтингу JavaScript. Тоже самое касается и WASM, ибо для взаимодействия с браузером всеравно нужен JavaScript. Является ли это корректным показателем популярности JavaScript - спорно.
В случае с рейтингом GitHub тоже не все гладко. Github учитывает только то, что в Github, а ведь есть еще и Gitlab, BitBucket и пр. Помимо этого, часто на Github в репозитории размещают какие-то веб-страницы через GitHub Pages и тупо используют его как хостинг, но тем самым добавляя +1 к популярности HTML+ CSS + JS.
Метод расчет рейтинга IEEE Spetrum описан у них на странице. Согласно этой странице, они используют данные из 8-ми источников (CareerBuilder, GitHub, Google, Hacker News, IEEE, Reddit, Stack Overflow, Twitter) и они приплетают информацию с собственного сайта вакансий jobs.ieee.com и careerbuilder.com, в которых в основном представлены вакансии только из США. Поисковые запросы Google (среди поисковиков используют только его) они используют по тому же принципу что и TIOBE, с теми же проблемами, что я описал выше на примере TypeScript. В общем тоже совсем не лучший вариант.
Помню, кто-то хвастался каким-то рейтингом Wappalyzer - те вообще специализируется на веб-приложениях и там соответственно PHP вырывается сильно вперед.
По итогу, этими рейтингами можно только манипулировать (в рекламе, в спорах и пр.), но реальность они не передают. Хотя с другой стороны, а многие ли будут всматриваться в суть этих рейтингов?
Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.
P.S. Вспомнил, что видел какую-то рекламу каких-то типичных курсов, где про один из рекламируемых языков было написано, что "...язык X является 1-м по популярности согласно рейтингу Y, поэтому вы легко найдете работу..." и рядом с этой рекламой, была другая реклама от этой же конторы, где было написано тоже самое про другой язык, только там был упомянут уже другой рейтинг. В общем - манипуляция в чистом виде.
Кстати, на тему оптимизации SVG. Когда нет под боком редактора, часто выручает SVGOMG, который можно попробовать в виде веб-версии jakearchibald.github.io/svgomg/. Неплохо так чистит. Но и как и в других оптимизаторах, могут "упрощаться" кривые, что в свою очередь может сказаться на анимации.
Что касается самой SVG анимации, то с ней, откровенно говоря, встречал много проблем и то же аппаратное ускорение может не работать (например потому что GPU или драйвер в blacklist) или может работать с багами, особенно если еще и присутствуют тяжелые SVG фильтры.
Что касается сложной анимации, то на слабых системах (в т.ч. старые, но активно используемые Android устройства), с браузерами на основе Chromium при работе с Canvas (и WebGL в частности) вычисления можно выполнять в WebWorkers с отрисовкой в OffscreenCanvas. Это помогает разгрузить основной поток, что благотворно влияет на общую производительность. Это хорошее решение, если очень надо отображать постоянную, сложную, контролируемую анимацию, даже на слабых системах. Хотя конечно и у WebGL тоже багов хватает.
Поэтому для простых анимаций пока отдаю предпочтение CSS и JS через WebAnimation API, ибо это куда стабильнее и более контролируемо.
Уважаемые пользователи федеральной информационной системы «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении»! Сообщаем Вам о том, что поля «СНИЛС», «Гражданство», «Форма обучения», «Источник финансирования», «Форма получения образования на момент прекращения образовательных отношений» станут обязательным для заполнения в шаблонах федеральной информационной системы «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» с 1 января 2021 года
Пытался юзать x2go для Visual Code (еще до того, как там появилась поддержка remote access) — тормозит рендер редактора. Подсветка синтаксиса языка идет в режиме «slowmotion». Вполне возможно, как уже упомянул boblenin, проблема из-за отрисовки веб-содержимого.
Также при не самом стабильном LTE 4G (потери пакетов), клиент нередко виснет намертво, но при этом ssh работает. Снижение качества почему-то особо не решало проблемы.
В третьих — как уже выше описали — проблемы с раскладкой при использовании клиента на Windows.
Но тем не менее, при использовании стабильного Ethernet, x2go является интересным решением для запуска графических linux программ на удаленной машине, даже при низкой пропускной способности канала.
Винер был очень колоритным ученым. Когда по теории систем делал курсовую и разбирал Кибернетику именно 1-го порядка, изучил его бестселлер «Кибернетика, или управление и связь в животном и машине». Классная смесь инженерно-математического мышления с филосовским подходом.
Кстати Винер был человеком достаточно рассеяным и забывчивым с чем связано достаточно много веселых легенд.
Например анекдот про него
Отец кибернетики Норберт Винер славился чрезвычайной забывчивостью.
Когда семья Винера переехала на новую квартиру, его жена положила ему в бумажник листок, на котором записала их новый адрес, так как отлично понимала, что иначе муж не сможет найти дорогу домой.
Тем не менее, в первый же день Норберт Винер умудрился потерять спасительный листок. Вечером, как ни в чём не бывало, он поехал по своему прежнему адресу. Когда обнаружилось, что в старом доме уже никто не живёт, он в полной растерянности вышел на улицу. Там Норберт Винер сообразил, что надо делать. Он подошёл к стоявшей неподалеку девочке и сказал:
— Извините, возможно, вы помните меня. Я профессор Винер, и моя семья недавно переехала отсюда. Вы не могли бы сказать, куда именно?
Девочка выслушала его очень внимательно и ответила:
— Да, папа, мама так и думала, что ты всё-таки забудешь.
Классно для изучения проходить классический набор квестов от LucasArts на SCUMM движке, т.к. этот движок позволяет делать паузу (можно сказать «замораживая» момент игры) при чтении, не вызывая меню. Во время роликов тоже можно делать паузу для спокойного перевода субтитров.
Большинство квестов же не дают возможность «заморозить» момент игры, чтобы спокойно перевести непонятный участок. Пауза зачастую вызывает меню и пр. Это очень неудобно.
P.S. К сожалению в ремастерах Monkey Island, Full Throttle и пр. тоже вместо паузы вызывается меню. Приходится переходить в оригинальный режим.
Потихоньку «бунтарский дух» уходит из сообщества разработчиков Linux. Он был искренним, идейным, жестким, свободным, хакерским (в том старом смысле этого слова). При разработке ядра, удачно применялась смесь авторитарного стиля управления с либеральным. Но видимо
окончательно закончилась пора, когда можно было открыто послать всё в ж*пу и за короткое время сварганить аля Git.
Еще часто слышно:
1) «Этим все должна заниматься ORM»
2) «Надо просто увеличить кэш»
3) «Надо просто нарастить мощности»
4) «Это недо-БД. Вот postgres|oracle|MSSQL|… с этим сама справится»
5) «Некогда этим заниматься»
Иногда бывает удобно принудительно указывать на индекс в случае работы с большими таблицами и когда имеется несколько «частичных» индексов (partial index). Оптимизатор тут может долго гадать какой использовать или просто выбрать самый большой индекс, чтобы уж наверняка.
Еще подготовленные запросы — очень полезная штука.
И про лимиты не стоит забывать.
А вообще, если требуется серьезно поднять производительность работы БД(без повышения производительности аппаратной части), лучшим будет изучить хотя бы поверхностно, как ведет себя конкретная БД в определенных случаях(в транзакции; при первичной записи; что и в каких случаях попадает в кэш БД; как работает журналирование;… прочее...). Чуточку в настройках покопаться. И разобраться, как все вышеперечисленное между собой связано.
Да и в общем особенности реализации конкретной БД.
Многие оптимизации сами придут в голову, при понимании работы конкретной БД.
//------------------------
Ну и на мой взгляд, под производительностью стоит подразумевать не только скорость обработки запросов, но и объем потребляемых ресурсов. Бывает и такое, что ваш не самый частый запрос стал обрабатываться чуток быстрее, но выбил из кэша много полезного и часто используемого.
Если вас напрягает привязка к Google Firebase вы можете попробовать присмотреться к неполной альтернативе в виде Supabase (GitHub: https://github.com/supabase/supabase), которое является Open Source решением и большинство функционала которого базируется поверх уже знакомого многим PostgreSQL.
У Supabase в облачном варианте также есть бесплатные тарифы для ознакомления, но в отличие от Firebase, Supabase можно полноценно развернуть на своем сервере.
Конечно Supabase не является полноценной альтернативой Firebase, но какую-то часть задач вполне может на себя взять.
С учетом того, какие нередко обновления идут, не удивлюсь если вскоре успешность установки этих обновлений будет зависеть от прохождения игры, типа "Не прошел игру - получай проблемы с гибернацией."
Да и техподдержке будет что ответить: "У вас проблемы с тачскрином? Попробуйте
перезагрузить компьютерпройти финального босса при обновлении..."Обратите внимание пожалуйста на разницу этих двух примеров:
и
Несколько моментов:
В первом случае импортируется "что-то", что далее будет именоваться как
Barи нет никаких гарантий, что это будет именно классFoo. Во втором случае, вы явно импортируете конкретно классFooи при помощи оператораasчетко даете понять ревьюверу, что вам необходим именно классFoo, но в данном модуле он будет именоваться как классBar.Далее, если взглянуть на первый вариант, будет ли очевидно без помощи IDE, что для того, чтобы понять, что такое
Barи какое у него назначение, вам нужно будет в справке прочитать раздел про классFooмодуля bar. Во втором случае, вcе гораздо очевидней (классFoo, модульbar);В JS, где с контролем типов и так все грустно (привет нарастающей популярности TypeScript), встроенная проверка того, что импортируется именно класс
Fooбудет не лишней. Если кто-нибудь случайно или специально сделает какой-то другой класс экспортируемым по умолчанию, то во втором случае вы сразу получите ошибку импорта. А вот в первом случае вы получите ошибку об отсутствии в объекте каких-то методов или свойств и не сразу догадаетесь, что это связано именно с некорректным импортом.Код обычно читают намного чаще, чем пишут, поэтому чем очевидней код при чтении, тем лучше. В любом случае, стоит придерживаться соглашений по стилю кода (в т.ч. по экспортам/импортам), которые уже приняты в проекте.
Хорошее объяснение, почему не рекомендуется
export defaultесть в Google TypeScript Style Guide (раздел "Экспорт") (хоть и TS, но также подходит и к JS).Пример поведения, который не всегда является желанным:
bar.ts :
custom-module.ts:
Потом при ревью, отладке и пр., в голове приходится держать, что
Foo === Bar, что не всегда очевидно и может приводить к неприятным неожиданностям в коде.Вы обратили внимание на очень хорошие моменты:
Верблюжий/змеиный регистр
Что касается "верблюжий/змеиный регистр" — такая формулировка нередко встречается в литературе. Термин "нотация" лучше (верблюжья/змеиная нотация), но такой термин нечасто используется по отношению к именованию файлов. Еще вариантом является просто слово "стиль", оно универсально и такой вариант использовался переводчиком Google JavaScript Style Guide.
В таком случае, оригинальную фразу вполне можно перевести так:
Параметры типа
Вы подметили один из проблемных в плане перевода терминов.
Проблема в том, что слова "типовое/типовые" многими воспринимается как синоним "типичное" или "стандартное" (пример повседневной фразы: "типовое решение"), особенно среди новичков и тех, кто незнаком с дженериками. Такое слово всегда должно писаться с явным ударением: "ти́повые параметры".
Вариант в виде "Обобщенный тип" часто представляется просто как "обобщение или дженерик", а термин "generic" в руководстве уже используется.
В итоге вариант "параметры типа" остался как компромисный, тем более про них в руководстве совсем немного описано. Наверное для таких спорных по наименованию терминологий, в тексте перевода было бы правильней указывать сноски-ссылки на термин в вики, MDN и пр., чтобы развеять возможные неточности.
А так, благодарю вас за уделенное внимание и полезные замечания. Если у вас в дальнейшем появятся предложения или замечания по тексту, как вариант, вы можете создать issue, поскольку тут ветка комментариев может уйти далеко от темы автора.
Данный перевод, как ни странно делался вручную, шаг за шагом. О пояснении причин и особенностей перевода опубликована целая статья.
Т.к. это именно руководство, т.е. документ, то при переводе важно было соблюдать точность, поэтому перевод делался буквальным, а не адаптированным и поэтому текст может читаться тяжело, о чем даже явно было описано в статье. При адаптированном переводе есть огромная вероятность внести отсебятину, которая может внести смысловую ошибку, что для руководства недопустимо. Оригинал также читается местами тяжело, с чем столкнулся также и переводчик Google JavaScript Style Guide.
Помимо этого, была необходимость подогнать текст перевода в соответствии с терминами «MUST», «SHOULD», «MAY» с учетом RFC. Как раз в недавнем обновлении оригинала уделили много внимания выделению этих терминов, что сразу же было учтено и в обновлении перевода.
В статье я специально выделил момент с автоматическими переводчиками, поскольку они часто и «MUST» и «SHOULD» переводят как «ДОЛЖЕН», а данное слово в русском языке несет обязательный оттенок. Поэтому SHOULD был в документе перефразирован под RECOMMENDED, что не нарушает RFC2119, но позволяет явно разделить по смыслу ключевые слова на три группы "должен", "рекомендуется", "возможно" (хотя сейчас я думаю, что более подошло бы слово "допустимо").
Также в оригинале есть ошибки, которые учтены в переводе и описаны в примечании. Помимо этого, в перевод добавлено множество уточнений и скорректировано форматирование.
То что пунктуация может хромать - это вполне возможно, поскольку когда приходится шаг за шагом переводить подобный текст - в глазах это уже мылится. Если есть предложение, как что-то можно сделать более читаемым, но с обязательным сохранением всех деталей оригинальной фразы - рад буду учесть. В любом случае проект открыт и вы можете предложить пожелания или правки.
По возможности, уточните пожалуйста, где именно данный перевод некорректен?
Спасибо за перевод. От себя добавлю несколько замечаний к самой статье:
TSLint давно заброшен и вместо него рекомендуется использовать ESLint;
Для организации кода лучше придерживаться использования модулей (ES Modules) вместо namespaces (см. ESLint
no-namespace, официальную документацию, или Google styleguide)по поводу типа Object - важно не путать
Object,objectи{}. Например (см. в песочнице):Подробнее про это можно прочитать тут на Хабре или в том же Google styleguide
А так хорошие практики и советы по TypeScript описаны в недавно обновленном руководстве от Google TypeScript Style Guide (+ см. перевод руководства на русский язык) о котором упоминалось в статье на Хабре. Там куда больше рекомендаций, учитывающих опыт разработчиков из Google, согласованных между собой и собранных в единый документ.
Тут недавно на Хабре, как раз под эту тему недавно была опубликована статья (перевод) "Хватит ссылаться на TIOBE", где обсуждалась проблема использования TIOBE как рейтинга. В своем комментарии к той статье я также упомянул и проблемы IEEE Spectrum (которые в чем то общие с TIOBE).
Так вот, метод расчет рейтинга IEEE Spetrum описан у них на странице. Согласно этой странице, они используют данные из 8-ми источников (CareerBuilder, GitHub, Google, Hacker News, IEEE, Reddit, Stack Overflow, Twitter).
Стоит обратить внимание, что к рейтингу они приплетают careerbuilder.com - в котором в основном представлены вакансии из США, а из поисковиков они используют только Google и выборка там идет (как и у TIOBE) на основе подсчета количества поисковых запросов вида `+" programming"`. Лично я считаю, что такой показатель может также указывать на отвратительное качество документации языка, раз постоянно гуглить приходится. Или вот пример из того комментария:
Этот пример также прекрасно подходит в случае с SQL и пр.
Лично я считаю, что и TIOBE и IEEE Spectrum и пр. совсем не отражают истинную популярность языков программмирования. Но зато данными этих рейтингов очень удобно манипулировать, например, в спорах или в рекламе всяких курсов и пр. Из того же комментария:
P.S. Простите что ссылаюсь на свой же комментарий из другой статьи - не хотелось совсем уж копипастить.
Спасибо за статью. Сам после того, как не раз столкнулся с холиварами с этими рейтингами, рассмотрел их метрики более внимательно и пришел к выводу, что по факту они не отражают истинную популярность языков программирования, о чем я как-то написал год назад статью у себя на сайте (не реклама - статья чисто по теме).
Если вкратце, возьмем например "индекс TIOBE", у которых индекс рассчитывается на основе подсчета количества поисковых запросов вида `+"<language> programming"` (https://www.tiobe.com/tiobe-index/programming-languages-definition/). Лично я считаю, что такой показатель может также указывать на отвратительное качество документации языка, раз постоянно гуглить приходится.
Например, у того же PHP очень неплохая документация расположена на официальном сайте, что снижает уровень излишнего гугления и соответственно рейтинга.
Или пример с TypeScript, который в итоге транспилируется в JavaScript. и если потом вылазят какие-то проблемы, вы можете гугля проблему неявно добавить +1 к рейтингу JavaScript. Тоже самое касается и WASM, ибо для взаимодействия с браузером всеравно нужен JavaScript. Является ли это корректным показателем популярности JavaScript - спорно.
В случае с рейтингом GitHub тоже не все гладко. Github учитывает только то, что в Github, а ведь есть еще и Gitlab, BitBucket и пр. Помимо этого, часто на Github в репозитории размещают какие-то веб-страницы через GitHub Pages и тупо используют его как хостинг, но тем самым добавляя +1 к популярности HTML+ CSS + JS.
Метод расчет рейтинга IEEE Spetrum описан у них на странице. Согласно этой странице, они используют данные из 8-ми источников (CareerBuilder, GitHub, Google, Hacker News, IEEE, Reddit, Stack Overflow, Twitter) и они приплетают информацию с собственного сайта вакансий jobs.ieee.com и careerbuilder.com, в которых в основном представлены вакансии только из США. Поисковые запросы Google (среди поисковиков используют только его) они используют по тому же принципу что и TIOBE, с теми же проблемами, что я описал выше на примере TypeScript. В общем тоже совсем не лучший вариант.
Помню, кто-то хвастался каким-то рейтингом Wappalyzer - те вообще специализируется на веб-приложениях и там соответственно PHP вырывается сильно вперед.
По итогу, этими рейтингами можно только манипулировать (в рекламе, в спорах и пр.), но реальность они не передают. Хотя с другой стороны, а многие ли будут всматриваться в суть этих рейтингов?
И вообще, касательно популярности языков программирования, напомню слова Бьерна Страуструпа:
P.S. Вспомнил, что видел какую-то рекламу каких-то типичных курсов, где про один из рекламируемых языков было написано, что "...язык X является 1-м по популярности согласно рейтингу Y, поэтому вы легко найдете работу..." и рядом с этой рекламой, была другая реклама от этой же конторы, где было написано тоже самое про другой язык, только там был упомянут уже другой рейтинг. В общем - манипуляция в чистом виде.
Спасибо за статью.
Кстати, на тему оптимизации SVG. Когда нет под боком редактора, часто выручает SVGOMG, который можно попробовать в виде веб-версии jakearchibald.github.io/svgomg/. Неплохо так чистит. Но и как и в других оптимизаторах, могут "упрощаться" кривые, что в свою очередь может сказаться на анимации.
Что касается самой SVG анимации, то с ней, откровенно говоря, встречал много проблем и то же аппаратное ускорение может не работать (например потому что GPU или драйвер в blacklist) или может работать с багами, особенно если еще и присутствуют тяжелые SVG фильтры.
Что касается сложной анимации, то на слабых системах (в т.ч. старые, но активно используемые Android устройства), с браузерами на основе Chromium при работе с Canvas (и WebGL в частности) вычисления можно выполнять в WebWorkers с отрисовкой в OffscreenCanvas. Это помогает разгрузить основной поток, что благотворно влияет на общую производительность. Это хорошее решение, если очень надо отображать постоянную, сложную, контролируемую анимацию, даже на слабых системах. Хотя конечно и у WebGL тоже багов хватает.
Поэтому для простых анимаций пока отдаю предпочтение CSS и JS через WebAnimation API, ибо это куда стабильнее и более контролируемо.
Я в этом году стал выпускником УрГЭУ и еще в начале года потребовалось подавать информацию о СНИЛС, что меня тогда слегка смутило и соответственно пришлось искать информацию по этому вопросу. Так вот, причину такого интереса учебных заведений к СНИЛС можно найти на сайте Рособрнадзора на странице "Формирование и ведение Федерального реестра сведений о документах об образовании и (или) о квалификации, документах об обучении".
Цитирую указанную там информацию
Причем согласно постановлению правительства от 31 мая 2021 г., никаких "или" нет. Это можно увидеть в указанном приложении (13 страница всего документа), где в списке необходимых данных, есть:
Проще говоря СНИЛС стал обязателен для получения итогового документа об образовании (диплома) и занесения его в базу Рособрнадзора.
Также при не самом стабильном LTE 4G (потери пакетов), клиент нередко виснет намертво, но при этом ssh работает. Снижение качества почему-то особо не решало проблемы.
В третьих — как уже выше описали — проблемы с раскладкой при использовании клиента на Windows.
Но тем не менее, при использовании стабильного Ethernet, x2go является интересным решением для запуска графических linux программ на удаленной машине, даже при низкой пропускной способности канала.
Кстати Винер был человеком достаточно рассеяным и забывчивым с чем связано достаточно много веселых легенд.
Когда семья Винера переехала на новую квартиру, его жена положила ему в бумажник листок, на котором записала их новый адрес, так как отлично понимала, что иначе муж не сможет найти дорогу домой.
Тем не менее, в первый же день Норберт Винер умудрился потерять спасительный листок. Вечером, как ни в чём не бывало, он поехал по своему прежнему адресу. Когда обнаружилось, что в старом доме уже никто не живёт, он в полной растерянности вышел на улицу. Там Норберт Винер сообразил, что надо делать. Он подошёл к стоявшей неподалеку девочке и сказал:
— Извините, возможно, вы помните меня. Я профессор Винер, и моя семья недавно переехала отсюда. Вы не могли бы сказать, куда именно?
Девочка выслушала его очень внимательно и ответила:
— Да, папа, мама так и думала, что ты всё-таки забудешь.
Большинство квестов же не дают возможность «заморозить» момент игры, чтобы спокойно перевести непонятный участок. Пауза зачастую вызывает меню и пр. Это очень неудобно.
P.S. К сожалению в ремастерах Monkey Island, Full Throttle и пр. тоже вместо паузы вызывается меню. Приходится переходить в оригинальный режим.
окончательно закончилась пора, когда можно было открыто послать всё в ж*пу и за короткое время сварганить аля Git.
1) «Этим все должна заниматься ORM»
2) «Надо просто увеличить кэш»
3) «Надо просто нарастить мощности»
4) «Это недо-БД. Вот postgres|oracle|MSSQL|… с этим сама справится»
5) «Некогда этим заниматься»
И про лимиты не стоит забывать.
А вообще, если требуется серьезно поднять производительность работы БД(без повышения производительности аппаратной части), лучшим будет изучить хотя бы поверхностно, как ведет себя конкретная БД в определенных случаях(в транзакции; при первичной записи; что и в каких случаях попадает в кэш БД; как работает журналирование;… прочее...). Чуточку в настройках покопаться. И разобраться, как все вышеперечисленное между собой связано.
Да и в общем особенности реализации конкретной БД.
Многие оптимизации сами придут в голову, при понимании работы конкретной БД.
//------------------------
Ну и на мой взгляд, под производительностью стоит подразумевать не только скорость обработки запросов, но и объем потребляемых ресурсов. Бывает и такое, что ваш не самый частый запрос стал обрабатываться чуток быстрее, но выбил из кэша много полезного и часто используемого.