dslf
+2
Как по мне, очередная книга из разряда «популярный психоанализ» — поверхностно, шаблонно. Если кого-то из читателей хабра действительно интересуют вопросы процессов мышления, очень рекомендую материалы lesswrong.com (переведенные материалы — lesswrong.ru) — крайне занимательное и полезное чтиво. Можно даже начать с легкого фанфика с серьезным содержанием «Гарри Поттер и методы рационального мышления», что примечательно, автор — тоже программист/математик.
dslf
0
Возможно, эту мысль уже высказывали, но советую также обратить внимание на предлагаемую Qt модель разработки многопоточных приложений, особенно модель разработки сущностей, наследуемых от QObject и их взаимодействие с потоками.

> При этом, если в том же Win API есть печеньки вроде WaitForMultipleObjects,
Когда-то тоже столкнулся с подобной проблемой. Чаще всего wait-condition + mutex/critical section + переменная, отвечающая за тип произошедшего события заменяют эту очень удобную плюшку.
dslf
+2
Странно, но по-моему, предложенный Вами вариант больше смахивает на
тяжеловестного уродливого монста, чем switch/if-else-if конструкции. Да и понятней они, что-ли.
dslf
0
Интересно, но пока что сыровато, было бы очень неплохо, если бы проект развивался дальше. Когда встала необходимость тестирования асинхронных методов и взаимодействий тоже ничего не нашел, а QTest для этих целей не очень удобный, пришлось писать свой велосипед, который до сих пор использую. Хотел бы поскорее более функциональную версию.
dslf
+4
Какая-то бессмысленная статья, на кого она рассчитана? Если на совсем новичков, которые даже не знакомы с STL — то, они ничего не поймут. Если для людей, которые знакомы с STL — то почему здесь нет сравнения с STL, почему не указано, что практически все контейнеры Qt используют парадигму «ленивого копирования», в отличии от STL, какие у неё преимущества, недостатки.

Статья выглядит как копипаст из какого-то обзорного учебника по Qt.
dslf
0
Я имел в виду код, который написан Вами. А суть проста: если Вы пишете на С++ — то и используйте инструментарий С++, а не СИ. Например, используйте строковые контейнеры (std::basic_string) для работы со строками, и std::basic_stream для работы с файлами. А если Вы пишите на СИ — то в приведенном выше коде замените вызовы операторов new [] и delete [] на calloc/malloc и free соответсвенно.
dslf
0
Да, точно:
dl.dropbox.com/u/4825327/MSVS2008%20-%20OfflineHelp%20-%20Document%20explorer.png

Я имею в виду, что document explorer, который был в старых студиях гораздо удобней, чем то, что появилось в первом сервис паке 2010й.
dslf
0
В 2008/2005 студиях, например, она была гораздо приятней.
dslf
+4
Хотелось бы, чтобы довели до ума Intellisens для C++ и вернули удобство offline-документации, потому что то, что есть сейчас — просто отвратительно. Также хотелось бы, чтобы исправили баг с вылетанием студии при включонной опции подгрузки task-ов из исходного кода.
dslf
0
Какая дикая смесь СИ и С++. И когда уже люди отучаться ТАК писать на С++?..
dslf
0
По-моему, в статье слишком уж преувеличина бесполезность универских предметов/знаний.

Закончил бакалаврат по специальности «Системная инженерия», кафедра Автоматики и управления в технических системах. Многие из предметов, которые читались в универе, по крайней мере концепции из них очень пригодились в работе. Насчет матана крайне не согласен: Вы бы еще написали, что дискретная математика не нужна программисту.

По-моему, Вы вообще путаете профильные курсы и высшее образование. На пост-советском пространстве пока что бизнес мало инвестирует в образование, соответсвенно и получается, что знания, которые в универах преподаются, не просто устарели, а еще и часто бывают не нужны. Но это не значит, что полностью все высшее образование не нужно.

В конечном счете, универ дает возможность человеку научиться учиться, если он еще этого не умеет.

Я думаю, что отличной идеей было бы повесить большой плакат рядом с приемной комиссией: «Университет не сделает из Вас специалистов, он только дает Вам возможность ими стать. Все зависит только от Вас».
dslf
+2
Называйте как хотите, в конечном счете, практически все, что вы перечислили — это частные случаи глупости и невежества. Как по мне, глупые люди с шилом в заднице — так можно охарактеризовать подавляющее большинство стартаперов. И никакие статьи им не помогут, пока они не поумнеют/набьют достаточное количество шишек. Ведь стартаперов нынче много, это модно-стильно-молодежно, а результатов добиваются немногие.
dslf
+1
Если уж на то пошло, то я бы добавил в этот список еще одну, самую распространненую ошибку, как мне кажется — «излишняя увлеченность стартапами». В большинстве случаев новоиспеченным стартаперам гораздо выгодней и эффективней будет «работать на дядю», чем заниматься стартапом.
dslf
+15
Как по мне, описанная Вами проблема высосана из пальца. Если у программиста, который применяет пары и кортежи кривые руки — это проблемы программиста, а не языка.
dslf
+2
Мне почему-то кажется, что слово троллинг в данной статье не только не уместно, а делает её похожей на статью из Луркоморья.
dslf
0
Насчет тяжело гуглится, я думаю вы какой-то другой гугл используете. Я когда писал МАНовскую работу в классе 11м без проблем нашел реализацию подобную Вашей.

В любом случае, упражняться, это конечно хорошо, но упражняться в том, что по большому счету, нигде не нужно — я думаю, это как минимум расточительно.
dslf
0
Мне одному кажется, что property в подобной реализации, мало того что уже тысячу раз писались, так еще и не нужны?
dslf
+1
слегка ошибся, это относится к этому посту:
habrahabr.ru/blogs/programming/121251/#comment_3984056
dslf
+1
> когда речь идёт об ООП головного мозга?
Ничего личного. Просто я, например, до сих пор не вижу смысла во всем описанном в статье.
dslf
–1
Опять-таки, где это применимо? Писать велосипеды — это весело и интересно, но вот, скажите, зачем? Одно из первых правил при разработке ПО: если что-то можно сделать простым и общепринятым способом — сделай так, не надо городить.
dslf
0
А где это применимо? Даже если и возникает такая ситуация, неужели настолько трудно создать интерфейс IAC и использовать такой же подход, как и в COM?

Где-то ниже уже говорили о использовании буста, для того, чтобы наложить ограничения на передаваемый в функцию объект. Если вы не хотите его за собой тянуть — dynamic_cast и assert вам в помощь.
dslf
–1
> … а потом напишите группирующий метод
Это признак ошибки в проектировании, как я уже и говорил.
dslf
–1
Так а зачем это выносить в один метод? Один конкретный метод решает одну маленьку конкретную задачу. Разбейте этот метод на 2: один использует функционал А, другой — В. Если не получается — у Вас явная ошибка в проектировании.
dslf
0
Вообще-то, в ситуациях, подобных описанной Вами, когда есть несколько ресурсов, которые используются только совместно — по сути, они являются одним ресурсом, и для него нужен только один объект синхронизации (мютекс, критическая секция, smart lock, неважно).

Да и вообще, идея объединения ресурса и объекта синхрониазации — не лучший способ организации многопоточной системы: это лишь усложняет систему.

И еще одно замечание: паттерны конечно хорошо, но необходимо пользоваться ими в меру, без фанатизма.
dslf
–12
Все, кто отписался выше и ниже — идиоты. Все сказал.
dslf
0
Писать о пользе TDD/BDD — это сейчас модно, стильно, молодежно? Ну надоели уже. Те, кто хотел — уже все для себя решили.
Нет, я не противник TDD. Я просто считаю его таким же самым инструментом, как и все остальное и применяю его я тогда, когда это уместно.
dslf
0
> wchar_t* x = L«Fred»; // нарушение
> char* x = «Fred»;
Вообще-то, и то, и другое нарушение, если уж на то пошло. Модификатор const здесь просто необходим.
dslf
0
А бинарников под 2010ю студию так и не сделали, придется снова собирать.
dslf
+6
Ну вот сколько еще можно эту заежженую тему обсуждать? И самое главное, зачем: все, кто хотел уже всё давно для себя решили.
dslf
0
Чем Вас не устраивают шоткаты перехода не следующую/предыдущую закладки.

Говорили о вкусах, закончили вкусами, да весь пост здесь вообще-то о вкусах, раз уж на то пошло :).
dslf
0
Еще одно небольшое замечание. Насколько я понимаю, в этом коде:
> Manager(manager).GetBonus;
Приведения типов нет вообще. Вы создали временный объект класса Manager с помощью конструктора копирования, который либо написали сами, либо за Вас его написал компилятор, а затем вызвали метод временного объекта.
dslf
0
Есть окно Bookmarks, с помощью которого доступны все выставленные закладки с указанием файла и номера строки, на которой была установлена закладка. Навигация с помощью данного окна удобней и наглядней, нет необходимости запоминать номера закладок, плюс ко всему есть возможность отключения закладки без её удаления.
dslf
+6
Прошу прощения, недописал:
> Явное приведение типов
Нет необходимости при правильном проектировании, приведенный Вами пример — плохой тон.

> TStringList
Приведенная Вами задача имеет более элегантное решение:
1) Через использование вспомогательного файла;
2) Считывание всего файла в контейнер/поток, вставка строки в начало контейнера/потока, перезапись файла/flush потока.

> Чтение данных с электронной почты
А класс, который напишет за Вас программу, Вы не хотите найти? Я не .Net программист, но уверен, что уже есть достаточное количество библиотек, реализующий данный функционал.

> Закладки в модулях кода
Они есть. Список всех шорткатов можно найти в документации к IDE, более того, можно самому выставить наиболее удобный шорткат.

> Поиск в модуле кода
Эта панель есть, Вы просто её не заметили. Более того, есть решарпер, о возможностях которого нет смысла здесь писать.

> Заключение
Язык программирования программисту следует выбирать исходя из задачи, которая перед ним стоит. Изучение ООП языка сводится к изучению его основной библиотеки/фрейворка, поэтому существенной разницы между ООП языками нет, есть небольшая разница между их фреймворками, те функции, которых нет можно найти в сторонних библиотеках. Хороший программист всегда будет писать хорошие программы, не важно на каком языке.

Спасибо, удачи в изучении языка.

dslf
+6
> Проверка на попадание во множество
Не нужно, если правильно использовать контейнеры и парадигмы, которые предлагает сам язык.

> Вложенные функции
Нет необходимости. Если Вы в них нуждаетесь, значит Вы неправильно спроектировали класс/группу классов.

dslf
+2
<зануда>
Ну и зачем в очередной раз разжевывать этот почти всем известный алгоритм?
Во всяком случае, это лучше чем писать посты о нвых айфонах.
</зануда>
dslf
0
Спешу заметить — дело здесь не в наличии/отсутсвии ТЗ, а в неправильной организации того самого общения, о котором Вы упомянули вначале.
> Уже тогда я четко понимал важность технологий общения в бизнесе.

За время, которое я работаю в сфере разработки ПО я понял одно: заказчик/начальник не знает чего он хочет, из него это надо вытягивать клещами. При этом все принятые решения следует записывать хотя бы в свободном виде. По сути, это называется совместное составление ТЗ. Кстати, очень важно убедить заказчика не скрывать информацию, которую он считает маловажной: лучше потратить некоторое время на фильтрацию информации от заказчика, чем проектировать и разрабатывать систему не представляя, как она будет использоваться и для чего она вообще нужна.
dslf
0
> Просто на осознание необходимости использовать инструменты учета времени у руководителей уходит очень много времени.

Кстати, есть один нюанс: все эти системы, методологии, и т.д. — все лишнее и все бесполезно пока руководитель смотрит на процесс разработки ПО как на автоматизированный конвеер. Уже чуть ли не на каждом столбе написано, что ПО создают люди, а не машины, и в управлении процессом разработки ПО надо отталкиваться от человеческого фактора. И даже при выборе инструментов, используемых при разработке следует это учитывать.
dslf
+2
Скорее всего, меня заминусуют, однако все решается довольно просто: введением небольшого количества бюрократии в виде ежедневных отчетов для новых/неопытных сотрудников. В отчете должны содержаться пункты: какие задачи были поставлены, какие выполнены и за сколько времени, какие проблемы возникли, решились ли они и сколько на них ушло времени. Если текучка кадров небольшая, то у менеджера не будет отбирать много времени чтение отчетов.

После того, как менеджер понял, что за человек с ним работает — можно отменять ежедневные отчеты и работать без них.

На составление отчета времени уходит от 5 до 20 минут максимум. На его чтение и анализ — 10 — 30 минут. Профит просто огромен, если менеджер хоть как-то разбирается в людях и проекте, который он ведет.
dslf
+2
В целом, концепция интерфейса приятна, однако он получился слишком сложным — не для изначальной целевой аудитории: как был в вашем первом макете недофотошоп, так им и остался.

Отличная идея в плане юзабилити — сделать тулбар в стиле контекстного меню.

Серьезные замечания по юзабилити и оформлению:
1) Не отрабатывается рисование/стирание по простому клику левой кнопки мыши — надо обязательно двигать мышь.

2) Ни один контрол не реагирует по-стандартному, как привыкли пользователи, на перетаскивание его мышью, особенно это напрягает при выборе цвета и настройки параметров кисти.

3) Про настройки параметров кисти отдельный разговор: если ползунок (Slider-control) имеет фиксированные значения — эти значения обязательно помечаются штрихами, например так:
----/ \--------
| | | |

4) Цветовая гамма, подобранная для контролов слишком тусклая, в неё приходится всматриваться т.к. на стандартном белом фоне плохо заметно активные элементы. Более того, нерабочие (disabled) элементы практически ничем не отличаются от рабочих. Ну а поскольку нельзя задать фон рисунка одни кликом, например, на черный — то этот пункт очень важен. Да и вообще, нужно больше яркости и насыщенности для интерфейса, он какой-то слишком сухой и строгий.

5) Иконка для зеркалирования недостаточна понятна, однако, это не настолько критично — практически любой человек, который хоть как-то любознателен на неё нажмет и поймет для чего она нужна.

6) Еще раз про ползунки — они слишком маленькие, по ним ОЧЕНЬ трудно попасть мышкой;

7) И еще раз про ползунки — они ДОЛЖНЫ работать так, как работают стандартные контролы винды, к которым привык пользователь. Если ты зажал левую кнопку мыши на определенной позиции — ползунок ДОЛЖЕН на неё установиться со временем, без дополнительных кликов.

8) Подсвечивание активных элементов (Hotlight для кнопок) слишком слабое как для белого фона, в принципе, это можно отнести к пункту 4.

Итог — из простого и понятного с первого взгяда приложения, действительно для детей, сделали совсем другое приложение — недофотошоп с ужасным юзабилити.
У меня растет племянник — пользоваться данной программой для него было бы просто неинтересно и сложно.

Спасибо, извините, если критика показалась слишком грубой. Продолжайте развивать проект, концепт хорош.
dslf
0
А те, кто разрабатывают инструменты — они создают то, чем им было бы самим приятно/удобно пользоваться.