Вообще при условий, что классических заправок на Марсе нет, Тесла-кары какой-нибудь повышенной проходимости — вполне себе вариант транспорта для красной планеты. Вероятно, это даже как-то в планах учтено.
Сразу появляется ряд удобных кейсов, о которых раньше и не задумывался:
1) показывать фото и видео с телефона на телеке
2) аналогично с фотиком
3) открытый ролик с youtube на телефоне можно в один клик отправить на телек
Потом, поднимать на никсах сервер самбы только для шаринга видеофайлов как-то не православно. NFS можно, но я даже не задумывался, поддерживает ли ее телек. С DLNA все просто и из коробки, работает стабильно, настроил и забыл.
Так как роль плеера отводилась устройству, аналогичному тому, что собирал топикстартер.
Тут, кстати, есть нюансы. Например, есть в телеке есть функция аля TrueMotion, то нужно внимательно настраивать свой проигрыватель.
Да и вообще, субъективно, телек встроенными средствами выдает более приятную глазу картинку, чем, скажем, комп с VLC. Вероятно, это уже особенности конкретного телевизора (у меня Sony XE8096).
У данного решения будет одна явная проблема — не потянет 4k фильмы. Если телек не умеет такое крутить, то пофиг, иначе — лишать себя очень качественной картинки.
Насчет AndroidTV на телеке я тоже сначала скептически относился, а когда купил — был приятно удивлен. Плюс DLNA решает проблему по проигрыванию контента с компа/NAS.
Даже по вашей таблице разница может достигать 4 раза. Это, мягко говоря, очень много.
На самом деле, виртуальные функции — это только половина беды. Основная проблема — код обрастает большим количеством крайне медленных dynamic_cast, мы теряет возможность грамотно оптимизировать код (потому что компилятор не знает, что нам прилетит в рантайме), в большинстве случаев теряем inline'овые функции (хотя final немного выправляет этот пункт) и т.д. и т.п.
Несмотря на то, что статья мотивационная, и, в целом, автор говорит правильные вещи (код все-таки нужно уметь писать самому), его пример — как раз тот самый случай, когда задачу надо очень хорошо гуглить.
Геометрические задачи тяжело решаются на компе. Написать robust алгоритм для общего случая чаще всего очень сложно. Автор вскользь написал, что существуют сложные многоугольники (они же самопересекающиеся), но задачу начал решать для простых. А вот я бы как раз посмотрел, как бы он эту задачу с помощью бумаги и карандаша решал применительно к сложным многоугольникам. Интересующиеся могут пойти в гугл с запросом «repair complex polygon» и убедиться, что это тема для многих научных работ и диссертаций, большинство решений которых ненадежны в общем случае. И задача эта очень важная и часто встречающаяся, потому что существует и в картографическом мире, и в полигональных моделях.
Поэтому, лично мое мнение, что начинать задачу нужно в первую очередь с понимания предметной области, а уже потом брать карандаш и писать свои велосипеды.
О, средства для статмоделирования мы любим! На первый взгляд библиотека выглядит очень хорошо, код написан понятно и качественно, приятно читать. Будем тестировать!
Видимо, были компании, где это нафиг не нужно. У нас в основном Бауманка + МГУ (ВМК/ФизТех), фундамент у всех довольно неплох. Также есть преподаватели высшей математики — все в почете.
Другое дело, берешь нынче студентов/выпускников на работу — тишина и глушь, ни программирования, ни математики.
Насчет, кстати, всяких там листков, досок и вот этого всего (судя по комментам, это много кого будоражит).
Не знаю, зачем могут, например, верстальщика заставлять на бумаги писать красивую верстку, но расскажу про нас. Наша команда занимается задачами типа rocket science, поэтому физика, математика, инженерное дело и программирование у нас очень в почете. 80% решаемых нами задач сначала очень тщательно прорабатываются на доске, обсуждаются, пишутся какие-то участки, и лишь потом происходит создание работающего алгоритма. Этот навык лично для нас — необходимый.
Когда мы просим решить какую-то простецкую задачу на бумажке (минут 10-15 для реально профессионала, в пределах часа — для новичка), естественно, самое важное для нас — как человек пытается ее решить. Если он забудет скобку поставить или там еще какую фигню напишет — не проблема. Да даже можем взять человека с живым умом, но слабым программированием — будет больше другими задачами заниматься. Но мой опыт в первую очередь говорит, что проблема в неумении решать задачи, а не писать их на листочке. Умеющие решать задачи, напишут ее и на доске, и на бумаге, и в ide, и в блокноте. Хороший спец без проблем берем маркер и пишет код, плохой — ноет, что бумага не нужна. Конечно, бывают бумагофобы, но для этого есть техническая часть, где будет понятно, что человек отлично разбирается в своей сфере.
«Существуют три вида лжи: ложь, наглая ложь и статистика».
Такие выборки хоть и интересные с точки зрения «среднего разработчика», на практике же ими пользоваться не стоит. Как минимум, в выборке не представлен уровень разработчиков. А это значит, что требования серьезных разработчиков меньше всего отразились в статистике (потому что, как правило, их хантят быстрее, чем они выкладывают вакансию). И судя по результатам свободных ответов, спецы бы в целом скорее выбрали другой порядок (3-2-1). Незнание алгоритмов и боязнь листочка — яркий тому пример.
valgrind, безусловно, софт уровня маст хэв. Хотя им нужно очень тщательно гонять софт, чтобы найти все проблемы, что не всегда легко.
Но в данном участке кода (и, по всей видимости, не только в нем) проблема от не очень хорошего знания самих плюсов, и фреймворка Qt в частности. Серьезно, ошибки уровня студентов 1 курса.
Да нет никакого секрета: есть 1 сканер, есть 2 секретаря. Документы пришли, кто-то из них засунул их в сканер, он автоматом сделал копию пачки и положил в дефолтную папку. Пришел второй секретарь, сделал тоже самое с другим доком. Часть из этого отобрали и аккуратно куда-то положили, на часть забили.
Тут вообще много всего сделано плохо, как я посмотрю. Лично для меня всегда является загадкой смешивание базовых объектов Qt и STL (строки, работа с файлами и т.д.) при полном непонимании их работы.
Параметром передается путь файла типа QString. Потом зачем-то вместо QFile используется ofstream. Потом строка конвертируется с помощью toLocal8Bit, то есть с большой вероятностью не latin символы потеряются. Ну и потом все эти проблемы с утечками.
Второй вычитывал этот файл раз в секунду, проверяя, что в нём поменялось с прошлого раза.
Можно было заюзать inotify (или аналоги на других системах) для удобного асинхронного информирования об изменениях в файлах. Ну и легким движением смотреть diff'ы.
Вопрос скорее концептуальный (идеи, предложения?): как быть с отсканированными документами? Доков много, секретари сканят все пачками в одну папку, не всегда все разбирается — адищенский ад в итоге.
Понимаешь, ты читаешь это отверждение от менеджера, который обосновывает свое офигенное участие в этом проекте. Он, якобы, молодец, что все поняли и оптимизировал.
Только в большинстве случаев это неправда. Убрать доступ к ФС телефона или выпилить AUX разъем — это кагбэ тоже «убрать свистелки и перделки, упростить все до 3 путей использования», но лучше ли это для конечного продукта? Или, например, убрать кучу проверок из кода, может, и упрощает чтение кода, но уменьшает надежность.
Я тоже, бывает, открываю наши большие проекты и думаю, нафига тут сколько всего нагородили, нельзя было проще? А в реальности начинаешь думать, как сделать лучше — и не всегда получается все эффективно сократить, есть куча нюансов, о которых знаешь только при глубоком понимании предметной области.
В оригинале, конечно, виден целый ряд проблем. Лично по моему опыту и рассказу автора, получилось следующее:
в компании был отличный спец с багажом знаний;
в компании была толпа некомпетентных разработчиков, которым все это нафиг не нужно. Не джунов, а именно людей, кто не хочет разбираться, и программирование для них — просто какая-то профессия, за которую неплохо платят (это сейчас вообще довольно популярная проблема). В итоге получилась ситуация, что проще сделать самому, чем объяснять коллеге, куда смотреть и что делать. И даже если он сделает, то сделает плохо и придется переделывать.
в компании Рики рубил идеи других разработчиков. Если разработчики бы были компетентными, они могли бы аргументированно могли продвинуть свои дели. Значит, идеи были говно.
в компании за 2 года (или сколько там в сумме?) никто не задал вопрос, что происходит. Там вообще, кроме Рика, кто-нибудь хоть какую-нибудь функцию выполнял?
большая нагрузка в режиме 12/7 свидетельствует о том, что был дедлайн, и чувак пытался как мог к нему успеть. Часто такой режим подразумевает костыли, отсутствие серьезного тестирования, говнокод и прочие проблемы разработки. И тратить время самого ценного сотрудника компании на то, чтобы в этом аду дедлайна объяснить джуну, как поправить конфиги — кощунственно.
любой адекватный развивающийся разработчик с радостью перепишет свой код. Потому что сегодня ты лучше, чем вчера. А завтра будешь лучше, чем сегодня. Отказываться от этой затеи можно только в тот момент, когда нет желание этим больше заниматься, либо дедлайн (и это самая частая причина, почему нет рефакторинга).
в итоге оказалось, что было еще целых полгода, за которое толпа бездарей (либо же новых сотрудников? это как-то не указано явно) смогла переписать проект. Чо-то какой-то небольшой проект, вам не кажется? Можем, Рики вполне мог делать какие-то отдельные части?
1) показывать фото и видео с телефона на телеке
2) аналогично с фотиком
3) открытый ролик с youtube на телефоне можно в один клик отправить на телек
Потом, поднимать на никсах сервер самбы только для шаринга видеофайлов как-то не православно. NFS можно, но я даже не задумывался, поддерживает ли ее телек. С DLNA все просто и из коробки, работает стабильно, настроил и забыл.
Тут, кстати, есть нюансы. Например, есть в телеке есть функция аля TrueMotion, то нужно внимательно настраивать свой проигрыватель.
Да и вообще, субъективно, телек встроенными средствами выдает более приятную глазу картинку, чем, скажем, комп с VLC. Вероятно, это уже особенности конкретного телевизора (у меня Sony XE8096).
Насчет AndroidTV на телеке я тоже сначала скептически относился, а когда купил — был приятно удивлен. Плюс DLNA решает проблему по проигрыванию контента с компа/NAS.
Не прошло и 3.5 лет :)
Полезных улучшений много, вы молодцы!
На самом деле, виртуальные функции — это только половина беды. Основная проблема — код обрастает большим количеством крайне медленных dynamic_cast, мы теряет возможность грамотно оптимизировать код (потому что компилятор не знает, что нам прилетит в рантайме), в большинстве случаев теряем inline'овые функции (хотя final немного выправляет этот пункт) и т.д. и т.п.
Геометрические задачи тяжело решаются на компе. Написать robust алгоритм для общего случая чаще всего очень сложно. Автор вскользь написал, что существуют сложные многоугольники (они же самопересекающиеся), но задачу начал решать для простых. А вот я бы как раз посмотрел, как бы он эту задачу с помощью бумаги и карандаша решал применительно к сложным многоугольникам. Интересующиеся могут пойти в гугл с запросом «repair complex polygon» и убедиться, что это тема для многих научных работ и диссертаций, большинство решений которых ненадежны в общем случае. И задача эта очень важная и часто встречающаяся, потому что существует и в картографическом мире, и в полигональных моделях.
Поэтому, лично мое мнение, что начинать задачу нужно в первую очередь с понимания предметной области, а уже потом брать карандаш и писать свои велосипеды.
Другое дело, берешь нынче студентов/выпускников на работу — тишина и глушь, ни программирования, ни математики.
Не знаю, зачем могут, например, верстальщика заставлять на бумаги писать красивую верстку, но расскажу про нас. Наша команда занимается задачами типа rocket science, поэтому физика, математика, инженерное дело и программирование у нас очень в почете. 80% решаемых нами задач сначала очень тщательно прорабатываются на доске, обсуждаются, пишутся какие-то участки, и лишь потом происходит создание работающего алгоритма. Этот навык лично для нас — необходимый.
Когда мы просим решить какую-то простецкую задачу на бумажке (минут 10-15 для реально профессионала, в пределах часа — для новичка), естественно, самое важное для нас — как человек пытается ее решить. Если он забудет скобку поставить или там еще какую фигню напишет — не проблема. Да даже можем взять человека с живым умом, но слабым программированием — будет больше другими задачами заниматься. Но мой опыт в первую очередь говорит, что проблема в неумении решать задачи, а не писать их на листочке. Умеющие решать задачи, напишут ее и на доске, и на бумаге, и в ide, и в блокноте. Хороший спец без проблем берем маркер и пишет код, плохой — ноет, что бумага не нужна. Конечно, бывают бумагофобы, но для этого есть техническая часть, где будет понятно, что человек отлично разбирается в своей сфере.
Такие выборки хоть и интересные с точки зрения «среднего разработчика», на практике же ими пользоваться не стоит. Как минимум, в выборке не представлен уровень разработчиков. А это значит, что требования серьезных разработчиков меньше всего отразились в статистике (потому что, как правило, их хантят быстрее, чем они выкладывают вакансию). И судя по результатам свободных ответов, спецы бы в целом скорее выбрали другой порядок (3-2-1). Незнание алгоритмов и боязнь листочка — яркий тому пример.
Но в данном участке кода (и, по всей видимости, не только в нем) проблема от не очень хорошего знания самих плюсов, и фреймворка Qt в частности. Серьезно, ошибки уровня студентов 1 курса.
Берем этот пример:
Параметром передается путь файла типа QString. Потом зачем-то вместо QFile используется ofstream. Потом строка конвертируется с помощью toLocal8Bit, то есть с большой вероятностью не latin символы потеряются. Ну и потом все эти проблемы с утечками.
Можно было заюзать inotify (или аналоги на других системах) для удобного асинхронного информирования об изменениях в файлах. Ну и легким движением смотреть diff'ы.
Вопрос скорее концептуальный (идеи, предложения?): как быть с отсканированными документами? Доков много, секретари сканят все пачками в одну папку, не всегда все разбирается — адищенский ад в итоге.
Только в большинстве случаев это неправда. Убрать доступ к ФС телефона или выпилить AUX разъем — это кагбэ тоже «убрать свистелки и перделки, упростить все до 3 путей использования», но лучше ли это для конечного продукта? Или, например, убрать кучу проверок из кода, может, и упрощает чтение кода, но уменьшает надежность.
Я тоже, бывает, открываю наши большие проекты и думаю, нафига тут сколько всего нагородили, нельзя было проще? А в реальности начинаешь думать, как сделать лучше — и не всегда получается все эффективно сократить, есть куча нюансов, о которых знаешь только при глубоком понимании предметной области.
Короче, что-то не так в этой компании.