Текстовые редакторы — это весело. Да-да. И то что в статье затронуто — это только начало начал. На эти структуры надо еще накинуть "веселье" полноценной поддержки unicode, right-to-left, cr/cr+lf (помню как одному редактору срывало крышу от манипуляций с документом с ошибочно вставленными им же cr+cr+lf). Теперь добавляем конечные автоматы для расцветки и разбора, теперь в фоне начинаем дёргать PSI/корёжить AST (и рисовать имена параметров в месте вызова, например).
Кстати, решил проверить и наткнулся на забавный эффект в IDEA
Код на Kotlin
data class aleph (val אאאאאא:Int = 1)
data class alpha (val αααααα:Int = 1)
fun main(args: Array<String>) {
println(aleph())
println(alpha())
}
Вывод (обратите внимание с какой стороны значение):
Не очень сложно, если собеседующий хорошо в теме. Цель квеста не в правильном ответе, а в правильном пути и в рассуждениях. И "правильный ответ" при одинаковых вводных может быть сильно разным. И, да, если друг маминой подруги непрошедшего кандидата может пройти любой квест типа "ваша БД тормозит", или "приложение списывает со счета неправильную сумму", или "сервис внезапно перезапускается", то он красавчик.
PS: к примеру, 23-х летнего сеньора — это такая ирония?
Да, кстати. Я почти всегда, если нанимаю разаботчика БД или DBA, если вижу, что кандидат адекватен, то делаю небольшой квест «Есть жалоба, что БД тормозит, что делаем?». На C#, Java лучше немного другие квесты.
Начал читать скептически, но это действительно компактная и в меру точная статья. «В меру точная» в том смысле, что для каждой рекомендации есть кучка контрпримеров, но так-то в жизни именно эти пункты — стандартные азбучные ошибки начинающего руководителя.
Сейчас, пожалуй, да. Но есть 2 тренда, которые напрочь это портят: во-первых, массовый исход уже не малого, а среднего бизнеса в облака (и вот у вас уже нет «недоступного напрямую»), во-вторых на горизонте IoT таки маячит — там все проблемы обновлений конечных устройств, просто еще на пару порядков хуже (например, Брюс Шнайер, часто об этом пишет в блоге и даже книгу собирается выпустить). Но с приходом этих трендов вопрос «почему админы не патчат» становится слегка бессмысленным.
А ведь я пытался всерьез читать статью до «Нехватка составит примерно 2 млн человек».
Эта фраза выглядит высосанной из пальца. Если только нехватка 2 млн, то сколько всего их надо? 5? 10? К каждому админу по безопаснику? Проверил источник по ссылке, но нет, переведено правильно: «But the global shortage of cybersecurity professionals will reach 2 million by 2019, according to ISACA, a global non-profit IT advocacy group.»
Стоп, а что за ISACA? Погуглил. А… они же продают услуги по сертификации, обучению и консалтингу. Ну-ну.
На самом деле дефицит есть. Только дефицит не «безопасников с сертификатами», а дефицит средней компетентности в ИБ в ИТ. Этот дефицит не перекрыть отдельными cybersecurity professionals.
Не-не-не. Просто с такими KPI подразделения быстро научатся перекладывать ответственность и искать виноватых. И тут мониторинг скорее помеха, чем профит. Админы приложения: "Это не у нас, это у DBA", DBA: "А чо мы-то? Это проблема админов сервера.", админы сервера: "У нас проблем не было, спросите у админов СХД", админы СХД: "ничо не знаем, у нас SLA latency 20 мс при 1000 IOPS".
Вот да. Более-менее общепринятых стандартов SQL было несколько (89, 92, 99, 2003, 2008, википедия подсказывает, что есть еще 2011, и 2016). Причем, например, СУБД не может быть полностью быть SQL92-compliant и SQL99-compliant: стандарты противоречат в некоторых нюансах. Я из любопытства читал драфты этих стандартов — там изрядное количество какого-то лютого трэшака, который не реализует и не использует никто. Я не знаю, сколько надо выкурить самокруток из книг Дейта и Кодда и чем их надо забивать, чтобы придумать этот фарш. Ах, да, стандарт этот найти бесплатно не так-то и просто. Видимо из-за это оторванности от практики, закрытости и объёма этот стандарт никто не использует (в отличие от спек C++, C#, Java, ECMAScript и т.п.)
Я вряд ли ошибусь, если скажу, что 99% "SQL-совместимых" СУБД это MySQL(+Maria), PostgreSQL, MS SQL Server, Oracle и SQLite. Да-да, я понимаю, что есть еще кучка древних и/или нишевых (IBM DB/2, Sybase/SAP ASE, Terradata, MS Jet, H2, Firebird и прочая экзотика, плюс стали появляться облачные движки), но основная часть всё-таки первая пятёрка. Так вот, даже в этой пятерке шаг в сторону от SELECT name FROM users WHERE age > 18сразу приводит к несовместимости. Именно поэтому поддержка нескольких СУБД не так-то и распространена, особенно без ORM. И, наверное, ни одна из них не реализует стандарт SQL.
А как эти СУБД "реализуют стандарт SQL"? А по принципу шведского стола: СУБД выбирает чуть ли не до абзаца чему именно соответствовать и говорит "я поддерживаю SQL". На этом фоне MS C++ просто образец дисциплинированности реализации стандарта.
И вишенкой на торте: у самих СУБД между версиями весьма большие различия.
Я остановился на Coollaboratory Liquid MetalPad. Он изначально в виде фольги и приплавляется к процессору. Пару лет у меня работал комп, в котором был металпад, потом у меня сдохла материнская плата (она была сильно старше). Я легко отковырял остатки старого интерфейса, никаких ужасов, описанных в статье, заменил плату и работает уже полтора года. Стабильно, тихо, слегка разогнанно. Кулер Noctua NH-D14, процессор Xeon W3690 живёт на частоте ~3,9 при штатной 3,46, старая МБ Gigabyte GA-EX58-UD5 (прожила с 2009 до 2017), «новая» — ASUS Sabertooth X58.
Цинично, но бизнес платит за результат и, в большинстве случаев, бизнесу всё равно сколько программистов выгорит, если решение на унылой технологии в сумме в несколько раз дешевле и будет раньше.
Нам, программистам, конечно, хочется работать с удобными современными технологиями. Хорошо, что а) сейчас рынок кандидата и мы просто можем проголосовать ногами, б) современные технологии часто дают и бизнесу эффективные решения.
Да-да, я много раз видел, как труъ программисты на Scala/Java/C#/C++ тыкали пальцами в «недопрограммистов» на PHP/1C/VBA/Access с подобными аргументами («у вас наследования и ООП нет», «у вас многопоточности нет», «у вас памятью управлять нельзя», «динамическая типизация, фуууу», «русские буковки в переменных — вы дебилы»). А потом вторые выводили за месяц решение нужное бизнесу за месяц-два, а первые за это время как раз заканчивали «проектирование каркаса внутреннего движка логирования».
Бизнес платит за результат. Да, в этих «языках второго сорта» низкий порог входа и есть много «совсем не гуру», но у бизнеса именно такие задачи, бизнес готов платить за это. Отформатировать эксель так, чтобы на листик поместилось. Посчитать НДС, чтобы копейки сошлись. Вывести список товаров с фотками.
Но высококвалифицированные разработчики на «языках второго сорта» тоже есть и нужны. Большинство из них знает 3-4 смежных технологии, но получает деньги именно за «второсортную»: в рамках тех же платформ есть и сложные задачи. Вокруг таких сильных специалистов часто растут очень эффективные команды, в которых и «рядовые» тоже развиваются.
Несколько моментов:
println(::main)отсыпетсяinnerпревращаютсяНу то есть всё в целом ожидаемо, но интересно.
Текстовые редакторы — это весело. Да-да. И то что в статье затронуто — это только начало начал. На эти структуры надо еще накинуть "веселье" полноценной поддержки unicode, right-to-left, cr/cr+lf (помню как одному редактору срывало крышу от манипуляций с документом с ошибочно вставленными им же cr+cr+lf). Теперь добавляем конечные автоматы для расцветки и разбора, теперь в фоне начинаем дёргать PSI/корёжить AST (и рисовать имена параметров в месте вызова, например).
Код на Kotlin
Вывод (обратите внимание с какой стороны значение):
Не очень сложно, если собеседующий хорошо в теме. Цель квеста не в правильном ответе, а в правильном пути и в рассуждениях. И "правильный ответ" при одинаковых вводных может быть сильно разным. И, да, если друг
маминой подругинепрошедшего кандидата может пройти любой квест типа "ваша БД тормозит", или "приложение списывает со счета неправильную сумму", или "сервис внезапно перезапускается", то он красавчик.PS: к примеру, 23-х летнего сеньора — это такая ирония?
Эта фраза выглядит высосанной из пальца. Если только нехватка 2 млн, то сколько всего их надо? 5? 10? К каждому админу по безопаснику? Проверил источник по ссылке, но нет, переведено правильно: «But the global shortage of cybersecurity professionals will reach 2 million by 2019, according to ISACA, a global non-profit IT advocacy group.»
Стоп, а что за ISACA? Погуглил. А… они же продают услуги по сертификации, обучению и консалтингу. Ну-ну.
На самом деле дефицит есть. Только дефицит не «безопасников с сертификатами», а дефицит средней компетентности в ИБ в ИТ. Этот дефицит не перекрыть отдельными cybersecurity professionals.
Ах, да, а разработчики после этого внедрить вообще ничего не могут потому что у админов KPI на сбои, а любое новое — риск сбоя.
Не-не-не. Просто с такими KPI подразделения быстро научатся перекладывать ответственность и искать виноватых. И тут мониторинг скорее помеха, чем профит. Админы приложения: "Это не у нас, это у DBA", DBA: "А чо мы-то? Это проблема админов сервера.", админы сервера: "У нас проблем не было, спросите у админов СХД", админы СХД: "ничо не знаем, у нас SLA latency 20 мс при 1000 IOPS".
Вот да. Более-менее общепринятых стандартов SQL было несколько (89, 92, 99, 2003, 2008, википедия подсказывает, что есть еще 2011, и 2016). Причем, например, СУБД не может быть полностью быть SQL92-compliant и SQL99-compliant: стандарты противоречат в некоторых нюансах. Я из любопытства читал драфты этих стандартов — там изрядное количество какого-то лютого трэшака, который не реализует и не использует никто. Я не знаю, сколько надо выкурить самокруток из книг Дейта и Кодда и чем их надо забивать, чтобы придумать этот фарш. Ах, да, стандарт этот найти бесплатно не так-то и просто. Видимо из-за это оторванности от практики, закрытости и объёма этот стандарт никто не использует (в отличие от спек C++, C#, Java, ECMAScript и т.п.)
Я вряд ли ошибусь, если скажу, что 99% "SQL-совместимых" СУБД это MySQL(+Maria), PostgreSQL, MS SQL Server, Oracle и SQLite. Да-да, я понимаю, что есть еще кучка древних и/или нишевых (IBM DB/2, Sybase/SAP ASE, Terradata, MS Jet, H2, Firebird и прочая экзотика, плюс стали появляться облачные движки), но основная часть всё-таки первая пятёрка. Так вот, даже в этой пятерке шаг в сторону от
SELECT name FROM users WHERE age > 18сразу приводит к несовместимости. Именно поэтому поддержка нескольких СУБД не так-то и распространена, особенно без ORM. И, наверное, ни одна из них не реализует стандарт SQL.А как эти СУБД "реализуют стандарт SQL"? А по принципу шведского стола: СУБД выбирает чуть ли не до абзаца чему именно соответствовать и говорит "я поддерживаю SQL". На этом фоне MS C++ просто образец дисциплинированности реализации стандарта.
И вишенкой на торте: у самих СУБД между версиями весьма большие различия.
Так что, да, "стандартный SQL" это миф.
на али по вашей ссылке есть 50 * 100 * 0,1 за 1351.
Мозг был прав скорее всего.
Вики:
Нам, программистам, конечно, хочется работать с удобными современными технологиями. Хорошо, что а) сейчас рынок кандидата и мы просто можем проголосовать ногами, б) современные технологии часто дают и бизнесу эффективные решения.
Бизнес платит за результат. Да, в этих «языках второго сорта» низкий порог входа и есть много «совсем не гуру», но у бизнеса именно такие задачи, бизнес готов платить за это. Отформатировать эксель так, чтобы на листик поместилось. Посчитать НДС, чтобы копейки сошлись. Вывести список товаров с фотками.
Но высококвалифицированные разработчики на «языках второго сорта» тоже есть и нужны. Большинство из них знает 3-4 смежных технологии, но получает деньги именно за «второсортную»: в рамках тех же платформ есть и сложные задачи. Вокруг таких сильных специалистов часто растут очень эффективные команды, в которых и «рядовые» тоже развиваются.