Файл был получен ученым при помощи бесплатного аудиоредактора Audacity и встроенного генератора шума.
«Я могу оспорить жалобу правообладателей, заявив, что у меня есть все исходники работы, что позволяет доказать ее оригинальность. Это всегда работало, и надеюсь, что этот способ не подведет и сейчас»
Все исходники, конечно, есть. А random seed от генератора у него тоже есть (чтобы воспроизвести получившийся шум)? =)
Сервисы аутентификации, магазин и обработка платежных методов, сервис доступа к статистике игроков, турниры, клановые войны и т.д. Наконец, часть игровой логики в сервере и клиенте сделана на питоне (та, которая не compute heavy).
идя собеседоваться лучше порешать задачки на тему, работодатели не прощают ошибок в sql-запросах
Возможно, не все работодатели сами могут пообщаться на более глубокие темы работы БД, поэтому придираются к синтаксису? Ладно еще поговорить про семантику where и having, но синтаксис?
В целом согласен, из питона там только Django, PHP-шных фреймворков вообще нет. И, кстати, эта картинка из параграфа про студентов, а данные из репорта HackerRank «2018 Student Developer Report»:
A total of 10,351 student developers completed the 10-minute online survey from October 16 to November 1, 2017.
То есть тут точность серьезно ниже, чем у SlashData.
Ну и у меня есть гипотеза, что когда интервьюируют человека на ASP.NET MVC приложение, спрашивают .NET Core и чем оно отличается от .NET Framework и отдельно про MVC и как оно реализовано в .NET (Core|Framework). Вполне может привести к тому, что все упадет в колонку .NET Core. На интервью PHP-шника будут спрашивать про PHP и меньше уделать внимания конкретному фреймворку. Этим может объясняться перекос в данных.
На картинке фреймворки, а не языки. Причем когда речь о JavaScript, Python или Java в большинстве случаев выбор фреймворка определяет то, как будет построено приложение. В C++ исторически сложился подход, когда в основном предоставляются библиотеки, а не фреймворки, поэтому на графике их и нет.
То, что я перечислил, это простой способ выяснить, насколько человек легко будет способен разобраться в БД, даже если прямо сейчас он не знаком ни с одной.
Если это вопрос ко мне, то я поговорю с этим джуниором в целом про алгоритмы, структуры данных, теорию множеств. Если там окажется все хорошо, то велика вероятность, что недостающее он легко освоит и джуниором можно брать.
Насчет Китая не уверен, там зарплаты у программистов повыше, чем в других отраслях, но не катастрофически. Преподаватель английского там в среднем зарабатывает больше, чем программист. Плюс там культурно престижнее быть артистом или чиновником например.
Индия — да, но исторически они гораздо раньше пост советских стран начали развивать и экспортировать IT услуги, у них «войти в IT» уже устаканилось и сбалансировалось. Где-то мне еще попадалась информация о том, что тамошние крупные IT компании объединились в картель с целью не допустить роста зарплат разработчикам, особенно начинающим.
По моим наблюдениям это очень локализованная тенденция, как раз в той географии, где зарплаты программистов сильно превышают зарплаты в других отраслях. Но прилично мешает, в найме например.
Во что выливается незнание SQL
1) Забывают определять индексы в результате через некоторое время приложение останавливается и не могут найти почему.
2) Не могут на практике применять нормализацию данных. Когда «мыслят объектами/сущностями» возникают из-за ошибок нормализации химерные результирубющие структуры таблиц.
С индексами ситуация очень частая, но быстроустранимая знающим человеком. Неправильно спроектированная база аукается гораздо сильнее.
Поэтому решая не требовать знания БД/SQL у разработчиков, нужно очень четко знать, кто именно будет эти вещи контролировать и исправлять. Видел один раз процесс в большой компании, когда после исполнения задачи разработчик передавал ее на ревью DBA, который должен был в случае чего кричать «Ты не пройдешь!» аки Гэндальф Барлогу. Мой внутренний эстет от такого бьется в истерике, но я понимаю, что люди выкручиваются как могут в сложившихся условиях.
Я не знаю, что такое ORM, но какие скилы нужны начинающему web backend девелоперу в итоге? SQL самый важный навык?
ORM — Object-Relational Mapping, в современных фреймворках предоставляет программисту способ обращаться к стораджу (базе данных) используя синтаксис языка и реляционные связи между объектами, абстрагируя конкретную базу данных. Т.е. ORМ за программиста сгенерирует и исполнит запрос к БД, предоставляя программисту интерфейс к эдакой виртуальной объектной БД.
Таком образом, без SQL можно вполне обойтись. Но я считаю, что эти знания определенно нужны, потому что использовать ORM без понимания того, какие запросы он сгенерирует и как они будут исполняться, это примерно как стрелять из ружья не зная, какой стороной к тебе оно повернуто.
А их точно не становится просто меньше, а не только в процентном отношении, если раньше это была необходимость и теперь трудоустраиваются специалисты которым это было нужно, не будет ли сейчас ситуации, что просто мало кому нужно этому учиться и работодателю дешевле будет кэш ускорить/увеличить на порядок?
Из источников, которые удалось найти, этого однозначно не видно. Я сам скорее склоняюсь к мнению, что нет, в абсолютных числах меньше не становится, периодически встречаю людей с опытом в 2-3 года, но хорошо ориентирующихся в этой области, и их вроде бы достаточно.
Все исходники, конечно, есть. А random seed от генератора у него тоже есть (чтобы воспроизвести получившийся шум)? =)
"Let me show you it's features! Ha-ha-ha" (с) Йорг
Возможно, не все работодатели сами могут пообщаться на более глубокие темы работы БД, поэтому придираются к синтаксису? Ладно еще поговорить про семантику where и having, но синтаксис?
То есть тут точность серьезно ниже, чем у SlashData.
Ну и у меня есть гипотеза, что когда интервьюируют человека на ASP.NET MVC приложение, спрашивают .NET Core и чем оно отличается от .NET Framework и отдельно про MVC и как оно реализовано в .NET (Core|Framework). Вполне может привести к тому, что все упадет в колонку .NET Core. На интервью PHP-шника будут спрашивать про PHP и меньше уделать внимания конкретному фреймворку. Этим может объясняться перекос в данных.
или на бумажке же найти декартово произведение:
Отсюда уже недалеко до джоинов в терминах SQL или до модели данных какой-нибудь простой задачи в реляционной БД.
Формулировки и определения нужны для экономии время при разговоре, но можно обойтись и без них, если видно, что человек просто волнуется.
То, что я перечислил, это простой способ выяснить, насколько человек легко будет способен разобраться в БД, даже если прямо сейчас он не знаком ни с одной.
6) уровни изоляции транзакций
Это если мы по два пункта за коммент добавляем и не ограничиваемся исключительно SQL, а про работу с БД в целом.
В моей практике всегда происходило так же.
Индия — да, но исторически они гораздо раньше пост советских стран начали развивать и экспортировать IT услуги, у них «войти в IT» уже устаканилось и сбалансировалось. Где-то мне еще попадалась информация о том, что тамошние крупные IT компании объединились в картель с целью не допустить роста зарплат разработчикам, особенно начинающим.
С индексами ситуация очень частая, но быстроустранимая знающим человеком. Неправильно спроектированная база аукается гораздо сильнее.
Поэтому решая не требовать знания БД/SQL у разработчиков, нужно очень четко знать, кто именно будет эти вещи контролировать и исправлять. Видел один раз процесс в большой компании, когда после исполнения задачи разработчик передавал ее на ревью DBA, который должен был в случае чего кричать «Ты не пройдешь!» аки Гэндальф Барлогу. Мой внутренний эстет от такого бьется в истерике, но я понимаю, что люди выкручиваются как могут в сложившихся условиях.
Этот кэш работодателю просто так не ускорить, потому что тут речь о физическом кэше процессора.
ORM — Object-Relational Mapping, в современных фреймворках предоставляет программисту способ обращаться к стораджу (базе данных) используя синтаксис языка и реляционные связи между объектами, абстрагируя конкретную базу данных. Т.е. ORМ за программиста сгенерирует и исполнит запрос к БД, предоставляя программисту интерфейс к эдакой виртуальной объектной БД.
Таком образом, без SQL можно вполне обойтись. Но я считаю, что эти знания определенно нужны, потому что использовать ORM без понимания того, какие запросы он сгенерирует и как они будут исполняться, это примерно как стрелять из ружья не зная, какой стороной к тебе оно повернуто.
Из источников, которые удалось найти, этого однозначно не видно. Я сам скорее склоняюсь к мнению, что нет, в абсолютных числах меньше не становится, периодически встречаю людей с опытом в 2-3 года, но хорошо ориентирующихся в этой области, и их вроде бы достаточно.