В плюсах появилось функциональное программирование? А можно и мне его отсыпать?
Начиная с C++11 появились встроенные лямбды, можно использовать замыкания, никто не мешает писать функции высшего порядка. Появились, например шаблоны с переменным числом параметров, кортежи, вывод типов… Всё это было и до стандарта C++11, правда в сторонних библиотеках.
Для начала нет необходимости объяснять всё подробно. Люди просто не обладают достаточными знаниями для того, чтобы начать бросаться перед ними фразами вроде «std::cout — это экземпляр класса ostream, представляющий собой стандартный буферизированный выходной поток, по умолчанию связанный с дисплеем консоли». Насчёт include все должно быть понятно сразу. Обычно до того, как показать программу есть некоторая вводная лекция, на которой затрагивают этапы сборки, в том числе и препроцессинг. Уже через месяц всё (за исключением глубокого понимания потоков) будет понятно, если не после двух лекций. Зависит от уровня аудитории на самом деле. Многие приходят из школы с пониманием что такое функция, например.
Вот я, например, не просил, чтобы делали эту статью. Поэтому, утверждать, что кто-то сделал какую-то работу для меня (и для той части аудитории хабра, которая её тоже не просила), совсем не корректно. Сделали что-то по своей (!) инициативе, разместили на публичном ресурсе… так чего же вы ждёте? Того, что вас будут носить на руках, только за то, что вы затратили какие-то личные ресурсы? Это уже даже не смешно. В общем, все просто…
Уникальная статья и хороший контент? Возможно, вот только статья вполне подойдёт и для случая с продажей тушенки или автомобилей, или чего-то еще. Для IT (причем вообще тут IT, к слову), полезность данного опуса лежит в области комплексных значений. Заявлять же «хороший контент» без обозначения явных критериев «хорошести», это, простите, моветон. Ещё и опубликовано в хаб «программирование».
Насчёт автора оригинального доклада тоже не все понятно. Ну, работает человек 10-20-30 лет «в области IT», и что с того? Интересно узнать какие были реальные проекты и достижения. Вот это, например, должен был сделать «хороший журналист». А конспект выступления… ну извините.
Зато получите +1 формальный признак для защиты диссертации (если вы конечно собираетесь её защищать) и баллы в рейтинг (если работаете штатным сотрудником института). Поэтому надо понимать, куда и с какой целью вы пишите. Постараюсь переформулировать свою предыдущую мысль: на Хабре несколько иной стиль постов и тематика. Я, например, не увидел связи поста с: «Учебный процесс в IT, Анализ и проектирование систем, Будущее здесь».
По сабжу… Ну есть ваша концептуальная модель и набор каких-то правил. Есть еще тысячи похожих моделей (я почти уверен!). Чем то, что вы предлагаете лучше (в корне отличается) от других схожих разработок? Что вы создали на основе предлагаемого в посте (программное обеспечение, новую методику обучения, реформировали систему образования РФ)? Что улучшилось (ухудшилось), когда вы все это внедрили и по каким критериям? Если бы вы рассказали об этом, то почитать пост было бы интересно (имхо).
А так получается что-то вроде: «У меня тут очередная свежая теория, коллеги...».
Какой стиль, так и отдаёт душком российской «науки»… Хабр все-таки не еще один псевдонаучный журнал ВАК РФ или сборник трудов международной псевдонаучной конференции.
Но мне хотелось бы поговорить об одной из самых важных и всегда актуальной: желание хорошо жить и хорошо зарабатывать.
В таком случае, лучше явно указать критерии хорошей жизни и хорошего заработка. Не для всех они одинаковы.
5% лучших специалистов получают 50% всех денег. 20% лучших специалистов получают 80% всех денег.
Можно ссылку на исследования российского рынка труда? Цифры необходимо чем-то подкреплять. Графики тоже. Я почти уверен, что этому даже на первом курсе института учат.
Не замечал ничего кроме черного фона под иконками.
Выбор временного пояса ассоциируется с местоположением. Этот значок обозначает точку на карте.
Логично то, что если вы открыли меню настроек, то получите доступ к настройкам (исключение авиарежим, но он там достаточно органично смотрится). А вот в виджете как раз нет авиарежима.
Под иконкой-черной дырой прячется набор других предустановленных гугловых приложений:
Ничего подобного не замечал.
Упражнение для телепатов: не заглядывая в инструкцию, догадайтесь, что находится за кнопкой с клизмой.
Скорее, упражнение для тех, кто не пользовался другими приложениями гугл. Стоит увидеть хотя бы раз логотип google maps, и все станет интуитивно понятно. Ассоциации с клизмой меня настораживают.
Что, думаете, произойдёт при нажатии иконки Wi-Fi? Не угадали, откроется меню настройки Wi-Fi.
Думаю, что это вполне логично. Для быстрого включения/выключения wi-fi есть соответствующий виджет, на котором еще и bluetooth есть даже, и другие полезные кнопочки.
Ну не такая уж и злостная венгерка, как например «rgfpArray») Все вполне пристойно, если подходить без фанатизма.
Тот же QtCreator генерирует имя поля для свойства в стиле «m_», что соответствует венгерской нотации. Ну а в Qt Coding Style ничего не написано по данному вопросу, если мне не изменяет память.
gSettings — префикс выражает глобальный статус переменной;
srcName, dstName — различие между объектами (например при копировании);
mName — префикс выражает статус члена данных (или "_" вместо «m», по аналогии с Python).
На странице 187, в данной книге есть таблица с префиксами и их значениями. На мой взгляд, префиксы куда удобнее для понимания и для работы в IDE, а также несут дополнительную информацию о назначении переменной (член данных, временная, статическая и так далее). К слову, именование констант с префиксом «kMaximumLength» выглядит куда лучше, чем «MAXIMUM_LENGTH».
В гайде очень много спорных моментов и очевидных вещей. Помимо не освещённых моментах, о которых писали выше, хотелось бы увидеть рекомендации по оформлению кода реализации классов, что-то вроде:
Foo::Foo( int arg1, int arg2 )
: mArg1( arg1 )
, mArg2( arg2 )
{}
Предметную область количественно оценить достаточно сложно. Оценить можно модель, например по количеству внутренних связей между элементами. Модель предметной области не из каких таблиц не состоит, это не даталогическая диаграмма базы данных. Если под моделью предметной области понимать базу данных, с оберткой для работы, то можно прийти к очень плохому решению с раздутыми контроллерами, и уйти от концепции активной модели. Но, сдается мне, что речь в статье идет о веб-программировании, а там это похоже распространено.
Да, но в больших проектах контроллеры напару с вюхами приходится повторно использовать. Например, почему бы не использовать навороченную логику грида с сортировкой, фильтрацией и другими плюшками для выбора значений. Своего рода продвинутый комбобокс, только на отдельной странице.
Сделайте отдельный контрол, и ваша проблема решится. Тут нет никакой связи с MVC, да и вообще с паттернами проектирования.
Небольшое замечание по статье. Как мне кажется, суть MVC эти (безусловно красивые) схемы не отражают. Вот первая схема… зачем там пользователь? Он что, делает контроллеру ментальный запрос? Как можно смешивать на одной схеме материальное и не материальное. MVC это составной паттерн проектирования, и в нем не предусмотрено взаимодействие с пользователем (точнее, описание пользователя, как элемента схемы), ну никак. Хотя, я вот тут смотрю на английскую вики, и вижу, что она со мной не согласна.
Прочитал обе статьи. Так и не понял, в чем же проблема, и как вы предлагает ещё решить.
Логика «зашита» во вьюшках, нельзя повторно использовать контроллеры (!!!)? Да зачем… Контроллер — всего лишь соединительный элемент. Хотите повторно использовать какую-то сложную логику? Сделайте в контроллере Стратегию, и пусть логику используют хоть все контроллеры, два ещё и разную логику, в зависимости от ситуации.
Что до компонентной архитектуры… Компоненты тоже должны взаимодействовать.
Давно уже ничего не писал в VS, но по-моему там хватает "#pragma once"… Думаю, что при изучении C++ проблемы переносимости кода и скорости компиляции вас не слишком заинтересуют.
А вообще CodeBlocks или SublimeText2 в сочетании с clang или gcc, и будет вам счастье с C++11 и без меню с большими буквами (привет, VS12!).
Скорее всего, будет что-то вроде: «Джарвис, сделай мне трёхмерную модель...».
Само понятие «язык программирования», на этом уровне скорее всего сотрётся, а наиболее важную роль будет играть окружение. Собственно оно и сейчас играет не последнюю роль (IDE, фрэймворки, библиотеки и так далее).
Начиная с C++11 появились встроенные лямбды, можно использовать замыкания, никто не мешает писать функции высшего порядка. Появились, например шаблоны с переменным числом параметров, кортежи, вывод типов… Всё это было и до стандарта C++11, правда в сторонних библиотеках.
Уникальная статья и хороший контент? Возможно, вот только статья вполне подойдёт и для случая с продажей тушенки или автомобилей, или чего-то еще. Для IT (причем вообще тут IT, к слову), полезность данного опуса лежит в области комплексных значений. Заявлять же «хороший контент» без обозначения явных критериев «хорошести», это, простите, моветон. Ещё и опубликовано в хаб «программирование».
Насчёт автора оригинального доклада тоже не все понятно. Ну, работает человек 10-20-30 лет «в области IT», и что с того? Интересно узнать какие были реальные проекты и достижения. Вот это, например, должен был сделать «хороший журналист». А конспект выступления… ну извините.
По сабжу… Ну есть ваша концептуальная модель и набор каких-то правил. Есть еще тысячи похожих моделей (я почти уверен!). Чем то, что вы предлагаете лучше (в корне отличается) от других схожих разработок? Что вы создали на основе предлагаемого в посте (программное обеспечение, новую методику обучения, реформировали систему образования РФ)? Что улучшилось (ухудшилось), когда вы все это внедрили и по каким критериям? Если бы вы рассказали об этом, то почитать пост было бы интересно (имхо).
А так получается что-то вроде: «У меня тут очередная свежая теория, коллеги...».
В таком случае, лучше явно указать критерии хорошей жизни и хорошего заработка. Не для всех они одинаковы.
Можно ссылку на исследования российского рынка труда? Цифры необходимо чем-то подкреплять. Графики тоже. Я почти уверен, что этому даже на первом курсе института учат.
Выбор временного пояса ассоциируется с местоположением. Этот значок обозначает точку на карте.
Логично то, что если вы открыли меню настроек, то получите доступ к настройкам (исключение авиарежим, но он там достаточно органично смотрится). А вот в виджете как раз нет авиарежима.
Ничего подобного не замечал.
Скорее, упражнение для тех, кто не пользовался другими приложениями гугл. Стоит увидеть хотя бы раз логотип google maps, и все станет интуитивно понятно. Ассоциации с клизмой меня настораживают.
Думаю, что это вполне логично. Для быстрого включения/выключения wi-fi есть соответствующий виджет, на котором еще и bluetooth есть даже, и другие полезные кнопочки.
Учитывая некоторую связь заголовка и картинки, вы не находите, что женщины могут обидеться?)
Тот же QtCreator генерирует имя поля для свойства в стиле «m_», что соответствует венгерской нотации. Ну а в Qt Coding Style ничего не написано по данному вопросу, если мне не изменяет память.
gSettings — префикс выражает глобальный статус переменной;
srcName, dstName — различие между объектами (например при копировании);
mName — префикс выражает статус члена данных (или "_" вместо «m», по аналогии с Python).
На странице 187, в данной книге есть таблица с префиксами и их значениями. На мой взгляд, префиксы куда удобнее для понимания и для работы в IDE, а также несут дополнительную информацию о назначении переменной (член данных, временная, статическая и так далее). К слову, именование констант с префиксом «kMaximumLength» выглядит куда лучше, чем «MAXIMUM_LENGTH».
В гайде очень много спорных моментов и очевидных вещей. Помимо не освещённых моментах, о которых писали выше, хотелось бы увидеть рекомендации по оформлению кода реализации классов, что-то вроде:
Сделайте отдельный контрол, и ваша проблема решится. Тут нет никакой связи с MVC, да и вообще с паттернами проектирования.
Небольшое замечание по статье. Как мне кажется, суть MVC эти (безусловно красивые) схемы не отражают. Вот первая схема… зачем там пользователь? Он что, делает контроллеру ментальный запрос? Как можно смешивать на одной схеме материальное и не материальное. MVC это составной паттерн проектирования, и в нем не предусмотрено взаимодействие с пользователем (точнее, описание пользователя, как элемента схемы), ну никак. Хотя, я вот тут смотрю на английскую вики, и вижу, что она со мной не согласна.
Логика «зашита» во вьюшках, нельзя повторно использовать контроллеры (!!!)? Да зачем… Контроллер — всего лишь соединительный элемент. Хотите повторно использовать какую-то сложную логику? Сделайте в контроллере Стратегию, и пусть логику используют хоть все контроллеры, два ещё и разную логику, в зависимости от ситуации.
Что до компонентной архитектуры… Компоненты тоже должны взаимодействовать.
Данных же.
Можете добавить еще один пункт… Что-нибудь про термины предметной области.
А вообще CodeBlocks или SublimeText2 в сочетании с clang или gcc, и будет вам счастье с C++11 и без меню с большими буквами (привет, VS12!).
Само понятие «язык программирования», на этом уровне скорее всего сотрётся, а наиболее важную роль будет играть окружение. Собственно оно и сейчас играет не последнюю роль (IDE, фрэймворки, библиотеки и так далее).