Вся красота разбивается в пух и прах моментом о требований регулятора и аудиторов, которые просто и ясно говорят «так нельзя» (причем как можно не говорят естественно).
На фоне конкурентов Spotify просто ужасен. UX гораздо хуже Google Play и Deezer. Пользовался платными подписками на всех трех. Spotify — совершенно ужасные алгоритмы рекомендаций (читай радио не работает). Совершенно нестандартные меню и действия типа «share» выполненые в кастомном стиле, что недопустимо на Android. Чтобы поменять качество потока на более-менее приемлемое надо перерыть все настройки (которые найти тоже квест еще тот!).
По сравнению с юзабилити Spotify Гугл просто эталон. Я с дуру на 3 месяца подписался на Spotify благо что за 33 пенса, так оно и того не стоит. Шаффл музыканта играет не все песни, радио крутит одни и теже песни для любого радио исполнителя. Интерфейс кошмар вообще.
Нет не из той-же. Вопрос не в том зачем нужен помощник, который делает все то, что вы описвли, а в том зачем нужен помощник, который вовсе этого не делает.
Алекса не знает русского.
На нее надо реально орать чтоб она услышала.
Она не для музыки (паршивая колонка).
Она не для поиска — один результат — не результат.
И что остается? Выключатель с голосовым управлением!
А почему минус человеку? Это именно так. Технический тест в первую очередь предназначен для отсева людей, болтающих языком. Не знаю как в других местах, но я провожу технический скрининг для одного из крупнейших банков. Вы удивитесь проценту людей, которые программистами не являются но претендуют на senior dev role.
Как можно определить технический кровень по 45 минутному интервью? Никак.
Я вам больше скажу — это ужасный проект. Это проект, который разрабатывался сотней человек последние 15 лет. Он содержит 4G исходников. Он собирается за 2.5 часа. Там нельзя включить максимальный кровень предупреждений поскольку слетает Visual Studio. Там много еще всякого.
Но… только такие проекты и имеют ценность.
Так что миллион ложных срабатываний — это не перувеличение. Это данность. И размечать неинтересные предупреждения статического анализатора — тоже не вариант. Помогает только отключение всего и включение только интересных, что убивает саму идею анализатора.
За всю историю моих мытарств с анализом кодовой базы я нашел только 1 (один) инструмент, который успешло распарсил все исходники (и разумеется я забыл его название :) ). Все кроссреференсеры, инструментирующие профайлеры, тулы типа парсера кода от Rational Rose — все падают.
Ну так в том и смысл, чтоб подсказки были когда поиск в интернете и не было когда поиск в истории. Если строка едина, то при поиске по посещенным URL нажатия уходят Гуглу. Паранойя однако!
> Много билд инженеров вы видели, которые настраивают и поддерживают системы мониторинга
Честно говоря — все кого видел именно этим и занимались. Иначе зачем они вообще?
> devops никак не завязан на ОС/архитектуру/ЯП.
Это было к «3. Реальный опыт использование контейнеров. » и далее.
>…
Мы — это все мы. Сообщество программистов и админов. Термин DevOps появился из ниоткуда. Всегда (с 60х годов точно :) ) программисты и админы в программерских конторах (или конторах с большой долей IT, как банки например) работали совместно. Может что-то изменилось и в волшебном мире вэб разработки есть какие-то отдельные админы, которые могут принимать решения поставить новую версию in-house software или нет, но в моем мире их нет. Решение за программистом, разрешение за бюрократами.
А всего-то надо не использовать шареные папки для бекапов (хоть с правами на запись к старым бекапам хоть без). Надо сервер бекапов со своим протоколом и клиент к нему. И все. Проблема шифрования бекапов решена. Не закрытым остается чтение оргинальных файлов с диска. Это да. Но уже сделаные бекапы ничто не потревожит.
> Но зачем?
Вот тут есть прямая выгода. Есть ненулевая вероятность, что потом вам прийдется столкнуться с этими коллегами по работе. Возможно в другой компании. Знакомства всегда полезны (даже на уровне «видел его раз на корпоративе, не помню имени»).
> О чём, например, вы с ним будете общаться?
Да ни о чем! Просто общяться. Хоть гимн советский орать :) Это опыт, новые ощущуения (вообще английское experience лучше подходит). Не ищите немедленной выгоды от этого — оно отложится в сознании и, например, на следующем интрервью вы будете меньше волноваться или просто в следующий раз проще будет знакомства заводить. Кто знает как оно именно на вас отразится.
Я вовсе не говорю «бросайте работу — идите лучше по отделам языком молоть» (это работа менеджеров :) ). Просто если представился случай — пользуйтесь. Оно-ж не стоит вам ничего кроме некоторого дискомфорта. А пользы может и не быть, а может и вагон.
Почитал коментарии. Ну и скучные-же вы! Денег на руки никто не даст. Примите это как данность. Из этого следует (с паршивой овцы хоть шерсти клок), что использовать халяву надо по полной. Не хотите пить — не заставляют. Не хотите общяться — не ходите.
Вот «правильные» хотелки:
— выбить как можно больше денег (нам они все равно не достанутся)
— первая статья расходов — алкоголь
— никакой работы во время (это относится к кружкам по интересам, если они не спонтанные)
— просто шикарно если довезут домой (хоть до метро)
Ну а если все-таки серьезно, то время надо использовать с пользой. Выпейте с директором, бизнесом, клиентами важными (их тоже иногда зовут), со смежной командой, с командой к которой вы вообще отношения не имеете. Заводите знакомства. Да, для интровертов сложно. Но раз в год и интроверт может выпить. Корпоратив — это шанс поговорить с теми, с кем вы в жизни даже не встретитесь вероятно (как насчет поговорить с членом совета директоров Fortune top 500, если вы, конечно, там работаете?).
Ну и что? Этот скриншот только показывает что 1) много народа работало (или много времени прошло) 2) они использовали ветки 3) инструмент неподходящий или настроен неправильно.
Число веток никак не влияет на сам факт существования истории. Хочется видеть историю без мерджей — напишите (найдите) визуализатор, который вам ее так покажет. При rebase даже написать визуализатор, который покажет то, что на скриншоте нет возможности. А потеря информации (тем более вводимой вручную) — это плохо.
А если разрабатываются тяжелые сервисы под Windows да еще и без контейнеров и не на Java, да деплоится все автоматически, но с бюрократией видимо никакого DevOps не будет, да?
Я вот тоже не понимаю что это такое и главное чем оно отличается от того что мы уже лет двадцать делаем? Автоматизированная сборка и деплой? Есть. Девелопер решает когда и что пойдет в прод? Есть. Команда эксплуатации? Нет, не видел.
Ну так что такое DevOps? Я прочел все коментарии. Вода и ничего кроме. Общие слова про «изменение культуры», «новый подход» и прочий белый шум.
То, что вы описали выше это обычный build engineer.
Да только проблема не в том, что анализатор не найдет ошибок, а в том что выдаст миллион ложных срабатываний. Единственный вариант использовать его с самых первых строк нового проекта. А они есть вообще на C++?
[Я к Splunk никакого отношения не имею]
А не используйте файлы вообще — коннектитесь к Splunk напрямую. Откройте несколько портов, каждому назначьте свой индекс и дуйте туда напрямую. Мы так log4cxx и log4net настроили (правда с кастомным TCP appender'ом, поскольку только UDP из коробки у них).
Да мы и не спорим вобщем. Я в основном говорил про то, что дают и недостаточно теории и очень отсталую практику. Пример с креевскими архитектурами как раз показателен. Надо было их давать! Нам кстати давали и именно о них я говорил «Сейчас применяю». Это-же не детали архитектуры — эту плату сюдя тыкать, а эту туда, а самые основы современного большого компьютинга — SIMD/MIMD/data driven computing и т.д.
Итого: очень мало программистской теории и катастрофический недостаток практики. Теория очень нужна. И именно cutting edge. Теория того что только в проекте сегодня, но по выходу из универа будет самый мэйнстрим. Практика как раз наоборот — самая база. Но база не уровня max(array), а уровня «напишите и отладьте модуль ядра Линукса» (условно). Только хардкор!
Зато философия, теория науки, библиотечное дело… да…
А я как раз учился в 1987. Да не было видеокарт, зато были «матричные модули» для ЕС ЭВМ. Разумеется нам про них никто даже не упоминал (я видел один на практике).
Про актуальность я не согласен. Дело-же не в том что видеокарт нет (сейчас вот квантовых компьютеров нет, да и ML процессоров толком тоже), а в том, что даже в далеком 1987 знали про параллельные вычисления и даже архитектуры тогдашних суперкомпьютеров обзорно давали. Проблема именно в том что обзорно.
Вот пример из 80х: был у нас один препод по языкам программирования. Так он засадил нам, тем, кто PL/1 худо бедно «смотрел», лекции и *лабы* по непроцедурным языкам программирования. Я впервые вообще узнал, что такие есть. Так вот GPSS (general purpose simulation system) настолько мне мозг сломал, что я языками увлекся и писал потом парсеры для всяких хитрых форматов как интерпретаторы простеньких языков (да со всеми пирогами в виде lex/yacc/pccts). Это между прочим в 90е под ДОС и OS/2!
Откуда-бы я такое узнал на работе (времена FIDO и написания бухгалтерского софта каждой маленькой конторкой)?
А знания про паралельные вычисления как раз из института. Сейчас применяю. Не знания разумеется — принципы. Теория была. Практика — нет.
Сейчас студентов надо ML да квантовым вычислениям учить. Да чтобы с лабами. А их Word да Joomla. Стыд это.
Вы-же понимаете что все это — азы где-то уровня курсов типа 101. Где еще 2-3 языка? Где машинное обучение, программирование на видеокартах (не игры), мат модели в финансах, grid computing, картография и гео-алгоритмы, моделирование сред? И т.д.
Универ это то место, где можно (и нужно) получить знания обо всем. И поскольку мы говорим об IT — обо всем в приложении к программированию (не скажу про админов, но видимо нечто похожее там тоже есть).
Вот была у нас теория вероятности, у всех видимо была… а на курсе программирования примеры реализации метода монте-карло давали? Не на математике (!), а на программировании: как параллелить, как балансировать, как, наконец, на кластер раскидать и т.д.? И так со всем — математика есть, но на вроде программистской специальности ничего сложнее условного нахождения максимума в массиве.
Ведь на работе работу работать прийдется. Надо монте-карло? Не до гео-алгоритмов уже! И наооборот.
Я не говорю изучать каждую область до уровня эксперта, да только условно раз в 10 надо углублять уровень изучения программирования.
www.thesun.co.uk/news/5745719/poisoning-of-russian-spy-in-salisbury-was-actually-a-plot-by-western-secret-services-to-humiliate-putin-and-complicate-relations-russia-claims
Американские:
www.washingtonpost.com/news/worldviews/wp/2018/04/04/britains-boris-johnson-accused-of-misleading-public-over-skripal-poisoning-evidence
Never again!
И что остается? Выключатель с голосовым управлением!
Как можно определить технический кровень по 45 минутному интервью? Никак.
Но… только такие проекты и имеют ценность.
Так что миллион ложных срабатываний — это не перувеличение. Это данность. И размечать неинтересные предупреждения статического анализатора — тоже не вариант. Помогает только отключение всего и включение только интересных, что убивает саму идею анализатора.
За всю историю моих мытарств с анализом кодовой базы я нашел только 1 (один) инструмент, который успешло распарсил все исходники (и разумеется я забыл его название :) ). Все кроссреференсеры, инструментирующие профайлеры, тулы типа парсера кода от Rational Rose — все падают.
Честно говоря — все кого видел именно этим и занимались. Иначе зачем они вообще?
> devops никак не завязан на ОС/архитектуру/ЯП.
Это было к «3. Реальный опыт использование контейнеров. » и далее.
>…
Мы — это все мы. Сообщество программистов и админов. Термин DevOps появился из ниоткуда. Всегда (с 60х годов точно :) ) программисты и админы в программерских конторах (или конторах с большой долей IT, как банки например) работали совместно. Может что-то изменилось и в волшебном мире вэб разработки есть какие-то отдельные админы, которые могут принимать решения поставить новую версию in-house software или нет, но в моем мире их нет. Решение за программистом, разрешение за бюрократами.
Вот тут есть прямая выгода. Есть ненулевая вероятность, что потом вам прийдется столкнуться с этими коллегами по работе. Возможно в другой компании. Знакомства всегда полезны (даже на уровне «видел его раз на корпоративе, не помню имени»).
> О чём, например, вы с ним будете общаться?
Да ни о чем! Просто общяться. Хоть гимн советский орать :) Это опыт, новые ощущуения (вообще английское experience лучше подходит). Не ищите немедленной выгоды от этого — оно отложится в сознании и, например, на следующем интрервью вы будете меньше волноваться или просто в следующий раз проще будет знакомства заводить. Кто знает как оно именно на вас отразится.
Я вовсе не говорю «бросайте работу — идите лучше по отделам языком молоть» (это работа менеджеров :) ). Просто если представился случай — пользуйтесь. Оно-ж не стоит вам ничего кроме некоторого дискомфорта. А пользы может и не быть, а может и вагон.
Почитал коментарии. Ну и скучные-же вы! Денег на руки никто не даст. Примите это как данность. Из этого следует (с паршивой овцы хоть шерсти клок), что использовать халяву надо по полной. Не хотите пить — не заставляют. Не хотите общяться — не ходите.
Вот «правильные» хотелки:
— выбить как можно больше денег (нам они все равно не достанутся)
— первая статья расходов — алкоголь
— никакой работы во время (это относится к кружкам по интересам, если они не спонтанные)
— просто шикарно если довезут домой (хоть до метро)
Ну а если все-таки серьезно, то время надо использовать с пользой. Выпейте с директором, бизнесом, клиентами важными (их тоже иногда зовут), со смежной командой, с командой к которой вы вообще отношения не имеете. Заводите знакомства. Да, для интровертов сложно. Но раз в год и интроверт может выпить. Корпоратив — это шанс поговорить с теми, с кем вы в жизни даже не встретитесь вероятно (как насчет поговорить с членом совета директоров Fortune top 500, если вы, конечно, там работаете?).
Число веток никак не влияет на сам факт существования истории. Хочется видеть историю без мерджей — напишите (найдите) визуализатор, который вам ее так покажет. При rebase даже написать визуализатор, который покажет то, что на скриншоте нет возможности. А потеря информации (тем более вводимой вручную) — это плохо.
Я вот тоже не понимаю что это такое и главное чем оно отличается от того что мы уже лет двадцать делаем? Автоматизированная сборка и деплой? Есть. Девелопер решает когда и что пойдет в прод? Есть. Команда эксплуатации? Нет, не видел.
Ну так что такое DevOps? Я прочел все коментарии. Вода и ничего кроме. Общие слова про «изменение культуры», «новый подход» и прочий белый шум.
То, что вы описали выше это обычный build engineer.
А не используйте файлы вообще — коннектитесь к Splunk напрямую. Откройте несколько портов, каждому назначьте свой индекс и дуйте туда напрямую. Мы так log4cxx и log4net настроили (правда с кастомным TCP appender'ом, поскольку только UDP из коробки у них).
Да мы и не спорим вобщем. Я в основном говорил про то, что дают и недостаточно теории и очень отсталую практику. Пример с креевскими архитектурами как раз показателен. Надо было их давать! Нам кстати давали и именно о них я говорил «Сейчас применяю». Это-же не детали архитектуры — эту плату сюдя тыкать, а эту туда, а самые основы современного большого компьютинга — SIMD/MIMD/data driven computing и т.д.
Итого: очень мало программистской теории и катастрофический недостаток практики. Теория очень нужна. И именно cutting edge. Теория того что только в проекте сегодня, но по выходу из универа будет самый мэйнстрим. Практика как раз наоборот — самая база. Но база не уровня max(array), а уровня «напишите и отладьте модуль ядра Линукса» (условно). Только хардкор!
Зато философия, теория науки, библиотечное дело… да…
Про актуальность я не согласен. Дело-же не в том что видеокарт нет (сейчас вот квантовых компьютеров нет, да и ML процессоров толком тоже), а в том, что даже в далеком 1987 знали про параллельные вычисления и даже архитектуры тогдашних суперкомпьютеров обзорно давали. Проблема именно в том что обзорно.
Вот пример из 80х: был у нас один препод по языкам программирования. Так он засадил нам, тем, кто PL/1 худо бедно «смотрел», лекции и *лабы* по непроцедурным языкам программирования. Я впервые вообще узнал, что такие есть. Так вот GPSS (general purpose simulation system) настолько мне мозг сломал, что я языками увлекся и писал потом парсеры для всяких хитрых форматов как интерпретаторы простеньких языков (да со всеми пирогами в виде lex/yacc/pccts). Это между прочим в 90е под ДОС и OS/2!
Откуда-бы я такое узнал на работе (времена FIDO и написания бухгалтерского софта каждой маленькой конторкой)?
А знания про паралельные вычисления как раз из института. Сейчас применяю. Не знания разумеется — принципы. Теория была. Практика — нет.
Сейчас студентов надо ML да квантовым вычислениям учить. Да чтобы с лабами. А их Word да Joomla. Стыд это.
Универ это то место, где можно (и нужно) получить знания обо всем. И поскольку мы говорим об IT — обо всем в приложении к программированию (не скажу про админов, но видимо нечто похожее там тоже есть).
Вот была у нас теория вероятности, у всех видимо была… а на курсе программирования примеры реализации метода монте-карло давали? Не на математике (!), а на программировании: как параллелить, как балансировать, как, наконец, на кластер раскидать и т.д.? И так со всем — математика есть, но на вроде программистской специальности ничего сложнее условного нахождения максимума в массиве.
Ведь на работе работу работать прийдется. Надо монте-карло? Не до гео-алгоритмов уже! И наооборот.
Я не говорю изучать каждую область до уровня эксперта, да только условно раз в 10 надо углублять уровень изучения программирования.