Cannonical пошел по пути Мелкомягких?
Уже начинают плавно намекать разработчикам,
как и на чем они должны писать приложения.
Quickly хы,… сей стек технологий как то странно не сочетается со спонсорством Qt.
В статье речь несколько про другое MeeGo, про настоящее, Harmattan же, скорее наследник Maemo, с некоторыми пакетами MeeGo, и измененным ради маркетинга названием.
Ну в свете нового стандарта, Qt foreach может быть и действительно не нужен,
но следует не забывать что, написан он был задолго до того.
А так кроме очевидного вылета: std::vector на foreach, ничего шокирующего не увидел,
реализация Qt foreach никогда и не претендовала на скорость,
она просто облегчала написание не критического итеративного кода.
Если мне нужно пройтись по контейнеру, в котором гарантированно не больше сотни-другой элементов,
неужели стоит пожертвовать чистотой кода ради, нескольких микросекунд?
Другое дело, в том что надо понимать когда не стоит этим злоупотребять.
В итоге считаю, ваш вывод крайне категоричным, и не вижу ничего страшного в умеренном использовании foreach по ситуации.
1. Безусловно, если вы изучаете Android, значит вы должны знать все об андройде. С этим я согласен. Я о том что не стоит изучать сегодня Android, завтра WP, после завтра Symbian. Мало того, положа руку на сердце, разницы в итоге не много, если представляешь общую канву построения мобильных приложений, то опираясь на опыт одной платформы, относительно не сложно путем сравнения перелезть на другую, если жизнь заставит.
2. Объясню свою позицию — жизнь коротка, а работы для нашей профессии сейчас очень и очень много и хорошей работы тоже очень много, не стоит тратить жизнь на работу, которая приносит много проблем и держит в постоянном стрессе. Человек проводит на работе большую часть своей жизни, поэтому от работы надо получать удовольствие.
3. Кстати я Бека не зря рекомендую, все-таки он основоположник TDD, мало того Java (с которой вы работаете) наверное, самая удобная платформа для TDD, для нее есть практически все нужные инструменты хорошего качества.
4. Если изучать физику процесса в каждом случае, то никакого времени не хватит (я не говорю про Just for fun, я именно про рабочую ситуацию), по идее рассматривать любое внешнее приложение/библиотеку стоит как черный ящик, до тех пор пока ее поведение соответствует вашим ожиданиям, если что-то пошло не так, тогда да, можно разобраться.
1. Изучение всего и много, очень хорошо пока вы учитесь, как правило это студенческие годы,
тогда да, можно учить и линуксы и потоки и over 9000 языков и фреймворков. Это время поиска себя.
К окончанию ВУЗа же, уже стоит найти свою нишу, то что больше по душе, и наращивать свои знания в этой области, потому как знать хорошо абсолютно все, невозможно. А отличное знание одной-двух-трех областей обеспечит вам и достойную жизнь и интересные задачи, с которыми приятно будет заниматься.
Это не значит, что не стоит пробовать, что-то новое, конечно, стоит, но только когда вы овладеете на достаточном уровне чем-то одним(двумя-тремя).
2. В наше время тестирование не закладывают в сроки только в самых дремучих и отсталых компаниях, не ходите туда работать. Не ходите работать и туда где сроки ставит только «Бизнес» — потратите нервы, испортите карму.
3. Проектирование — это здорово. Но проектирование != UML. Проектируйте так как вам удобнее. Не проектируйте большими кусками, если вы не старый бородатый дядька с 20+ годами стажа, от вас этого и не потребуют. Скорее всего максимум, что вы лично будете проектировать, это некоторые модули классов не более чем на 50-70. Разбивайте проектирование на подзадачи. Не проектируйте до последнего метода, все равно придется менять.
Что такое TDD автор не знает, никто не пишет ВСЕ тесты сразу после проектирования архитектуры. Тесты пишутся вместе с кодом. Автор, открываем Бека и читаем.
4. Капитанщина. На деле, гуру рекомендуют покрывать внешние вызовы тестами. Конечно, если недоступны родные тесты используемых библиотек. Если же они есть, изучите их, тесты — отличные примеры и документация возможностей.
В единственном я согласен с автором, хотя он высказал это в более мягкой форме — Пиши код блеять!
Обмазываются, до тех пор пока не потребуется вычислить и сохранить, ну не знаю, какой-нить момент импульса вращательного движения в нерелятивистской механике (взял с потолка).
Я правильно понимаю, что данный клиент будет работать только с репозитариями на GitHub? Или его можно использовать как клиент для любых git-репозиариев?
Такой вот вопрос хочу задать, я смотрю все свойства задаются строками.
Т.е. не используются какие-либо перечисления допустимых типов, а именно строки:
«cpp», «application» и т. д.
А как система отреагирует на некорректное значение, опечатку и т. д?
Я боюсь что cpp парсер для qt-creator писал далеко не один человек и писал он его не неделю, и если когда то в него была добавлена конвертация .toLatin1. то значит это было по какой0то причине необходимо, соответственно, неизвестно насколько просто будет исправить это сейчас, насколько я знаю автор плагина работает над этим.
Уже начинают плавно намекать разработчикам,
как и на чем они должны писать приложения.
Quickly хы,… сей стек технологий как то странно не сочетается со спонсорством Qt.
И футболки не красивые :(
но следует не забывать что, написан он был задолго до того.
А так кроме очевидного вылета:
std::vector на foreach, ничего шокирующего не увидел,
реализация Qt foreach никогда и не претендовала на скорость,
она просто облегчала написание не критического итеративного кода.
Если мне нужно пройтись по контейнеру, в котором гарантированно не больше сотни-другой элементов,
неужели стоит пожертвовать чистотой кода ради, нескольких микросекунд?
Другое дело, в том что надо понимать когда не стоит этим злоупотребять.
В итоге считаю, ваш вывод крайне категоричным, и не вижу ничего страшного в умеренном использовании foreach по ситуации.
2. Объясню свою позицию — жизнь коротка, а работы для нашей профессии сейчас очень и очень много и хорошей работы тоже очень много, не стоит тратить жизнь на работу, которая приносит много проблем и держит в постоянном стрессе. Человек проводит на работе большую часть своей жизни, поэтому от работы надо получать удовольствие.
3. Кстати я Бека не зря рекомендую, все-таки он основоположник TDD, мало того Java (с которой вы работаете) наверное, самая удобная платформа для TDD, для нее есть практически все нужные инструменты хорошего качества.
4. Если изучать физику процесса в каждом случае, то никакого времени не хватит (я не говорю про Just for fun, я именно про рабочую ситуацию), по идее рассматривать любое внешнее приложение/библиотеку стоит как черный ящик, до тех пор пока ее поведение соответствует вашим ожиданиям, если что-то пошло не так, тогда да, можно разобраться.
1. Изучение всего и много, очень хорошо пока вы учитесь, как правило это студенческие годы,
тогда да, можно учить и линуксы и потоки и over 9000 языков и фреймворков. Это время поиска себя.
К окончанию ВУЗа же, уже стоит найти свою нишу, то что больше по душе, и наращивать свои знания в этой области, потому как знать хорошо абсолютно все, невозможно. А отличное знание одной-двух-трех областей обеспечит вам и достойную жизнь и интересные задачи, с которыми приятно будет заниматься.
Это не значит, что не стоит пробовать, что-то новое, конечно, стоит, но только когда вы овладеете на достаточном уровне чем-то одним(двумя-тремя).
2. В наше время тестирование не закладывают в сроки только в самых дремучих и отсталых компаниях, не ходите туда работать. Не ходите работать и туда где сроки ставит только «Бизнес» — потратите нервы, испортите карму.
3. Проектирование — это здорово. Но проектирование != UML. Проектируйте так как вам удобнее. Не проектируйте большими кусками, если вы не старый бородатый дядька с 20+ годами стажа, от вас этого и не потребуют. Скорее всего максимум, что вы лично будете проектировать, это некоторые модули классов не более чем на 50-70. Разбивайте проектирование на подзадачи. Не проектируйте до последнего метода, все равно придется менять.
Что такое TDD автор не знает, никто не пишет ВСЕ тесты сразу после проектирования архитектуры. Тесты пишутся вместе с кодом. Автор, открываем Бека и читаем.
4. Капитанщина. На деле, гуру рекомендуют покрывать внешние вызовы тестами. Конечно, если недоступны родные тесты используемых библиотек. Если же они есть, изучите их, тесты — отличные примеры и документация возможностей.
В единственном я согласен с автором, хотя он высказал это в более мягкой форме — Пиши код блеять!
За подобные конструкции в коде:
надо наказывать.
А за подобные:
убивать.
Не поймите меня неправильно.
Такой вот вопрос хочу задать, я смотрю все свойства задаются строками.
Т.е. не используются какие-либо перечисления допустимых типов, а именно строки:
«cpp», «application» и т. д.
А как система отреагирует на некорректное значение, опечатку и т. д?
bugreports.qt-project.org/browse/QTCREATORBUG-7356
bugreports.qt-project.org/browse/QTCREATORBUG-4654