Я работаю программистом уже много лет, на протяжении которых, как это ни странно, я всё время что-то программирую. И вот какую интересную вещь я заметил: в коде, написанном мной месяц назад, всегда хочется что-то чуть-чуть поправить. В код полугодичной давности хочется поменять очень многое, а код, написанный два-три года назад, превращает меня в эмо: хочется заплакать и умереть. В этой статье я опишу два подхода. Благодаря первому архитектура программы получается запутанной, а сопровождение — неоправданно дорогим, а второй — это принцип KISS.

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

В этой статье я хотел бы поделиться своим опытом разработки одного виджета (элемента графического интерфейса), попутно осветив некоторые технологии и техники Qt.
Очень часто бывает необходимо дать пользователю возможность вставки строк и столбцов в таблицу или удаление их из неё. Как правило это реализуется так: надо выделить строку кликнув по хидеру и выбрать пункт в меню: select > menu > insert | delete. Это не совсем очевидно и интуитивно, как и то что строка вставляется перед текущей а не, например, после неё. Поэтому я написал виджет который снимает эту проблему.
Виджет выглядит как четыре кнопки, следующие за курсором по границе таблицы (хаха, это совсем как те пчелки, которые бегали за курсором на сайтах в эпоху вэб 1.0!). Можно было бы перегрузить QTableView, но тогда придется изменять все инстансы; вместо этого я написал отдельный виджет которые представляет из себя как бы панельку которая прикрепляется к уже имеющемуся QTableView.

Многие из тех кто занимаются разработкой на C++/Qt знакомы с такой средой как Qt Creator, создатели которой потрудились над дизайном не меньше чем над функциональностью. Но меня, как любителя темных цветовых схем и плоского минимализма, всегда не устраивали светлый фон панелек и градиентные заголовки.

Казалось бы, открытый исходный код — бери да меняй, но неопытность и лень останавливали меня, пока я не узнал про такую вещь как Qt Style Sheets, позволяющюю описать вид виджетов в формате css.

В данном уроке я расскажу в картинках как собрать приложение статически/провести статическую линковку/ отучить ваш *.exe от библиотек Qt — кажется это всё одно и тоже по своей сути

Вступление:

Лично я всё проделывал со свеженькой на данный момент Qt SDK с сайта Nokia( Qt 4.8 и SDK 1.2.1)
Сам я полный нуб в Windows, так как всё жизнь сижу на Linux, так что всё сопровождается картинками, для таких же нубов в винде, как я сам.

Введение

Диаграмма классов UML позволяет обозначать отношения между классами и их экземплярами. Для чего они нужны? Они нужны, например, для моделирования прикладной области. Но как отношения отражаются в программном коде? Данное небольшое исследование пытается ответить на этот вопрос — показать эти отношения в коде.

«Система должна быть спроектирована так,
чтобы оставаться как можно проще
после серии внесенных в нее изменений»
Бьярне Строуструп – программист, автор языка C++

Преамбула

В данной статье мне бы хотелось бы рассказать о довольно популярной, но так редко освещаемой на Хабре библиотеке Portable Components (сокр. POCO). Она будет полезна как разработчикам бизнес-логики программного продукта, так и в решении большинства прикладных задач. При всем изобилии кроссплатформенных библиотек для C++ всё больше людей сталкиваются с POCO лицом к лицу и не знают с чего начать. В данной статье я постараюсь описать технологии, заложенные в библиотеке и дать простейшие примеры решения некоторых задач. Также хотелось бы отметить, что за плечами библиотеки множество успешных как Open Source, так и коммерческих проектов.

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


Большинство разработчиков, скорее всего, представляют себе архитектуру только в приложении к конкретному проекту, т.е. можно часто услышать от них «архитектура ПО», однако это лишь малая часть того, что входит в общее понятие. Условно можно разделить глобальное понятие на несколько частей, от общего к частному. Можете представить их в виде пирамиды:

• Бизнес архитектура
• Архитектура информационных систем (потоки данных)
• Технологическая архитектура

Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

gollum подметил что в тексте картинки есть ошибка

Салют, хабр! Как дела?

Хотел немного подучится чему-то. Искал на хабре в хабе «Qt Software» хоть какой-то пост про юнит-тестирование в Qt. Не нашел. Тут я расскажу базовые вещи про юнит-тестирование на Qt (не ожидайте могучего шаманства). На самом деле, юнит-тестить в Qt довольно просто. Что бы узнать как это делать, приглашаю читать дальше.

В ряде случаев для написания функциональных приложений на QML без знаний C++ не обойтись, и, помимо умения на нём программировать, необходимо научиться интегрировать код C++ с языком QML. Именно этому и будет посвящен весь сегодняшний вебинар.

Посмотрев данный вебинар вы узнаете, как устроено декларативное окружение Qt и как оно связано с языком QML, а также поймете, что представляет из себя программа на QML с точки зрения C++. В первых вебинарах по разработке на QML и Qt Quick мы уже частично касались этого вопроса, но сейчас разберем его подробнее, вернувшись к элементарной программе «Hello, World!» и рассмотрев её с точки зрения C++.

Также в вебинаре мы рассмотрим возможности и порядок создания нового элемента, научимся экспортировать свойства из C++ в QML, и разберем, как создавать пользовательские сигналы и слоты.

Как сказал один из пользователей StackOverflow, «using SO is like doing lookups with a hashtable instead of a linked list». Мы снова обращаемся к этому замечательному ресурсу, на котором попадаются чрезвычайно подробные и понятные ответы на самые различные вопросы.

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

Буквально на днях случайно наткнулся на Хабре на статью о лямбда-выражениях из нового (будущего) стандарта C++. Статья хорошая и даёт понять преимущества лямбда-выражений, однако, мне показалось, что статья недостаточно полная, поэтому я решил попробовать более детально изложить материал.

Наша серия вебинаров, посвященная QML и QtQuick, продолжается, и сегодня мы вам расскажем про анимацию. Без анимации, то есть плавных переходов и поворотов, сейчас немыслим ни один качественный интерфейс, а значит упускать эти возможности QML попросту нельзя.

Анимации используются для создания визуальных эффектов и применимы к любому визуальному элементу. Анимации могут применяться для чисел и свойств, их можно использовать для создания пауз и задержек. Существует множество типов анимации (NumberAnimation для числовой анимации, ColorAnimation для переходов между цветами, RotationAnimation для поворотов, SpringAnimation и т.д.)

Для возможности задать, каким образом при анимации будет интерполироваться переход от начального значения к конечному, можно использовать переходные кривые (Easing curves). С их помощью можно анимировать элементы, например, по экспоненциальному закону (easing.type: "OutExpo").

Blockly — визуальный язык программирования с веб-интерфейсом. Создание программы осуществляется путём соединения блоков.



Некоторые демки:
Maze — используйте Blockly, чтобы пройти лабиринт.
Code — экспорт программы Blockly в JavaScript, Dart, Python или XML.

Химики любят говорить, что химия занимается исследованием грязных веществ чистыми методами, физика — чистых веществ грязными методами, а физическая химия, дескать, исследует грязные вещества грязными методами. В областях, традиционно относящихся к искусственному интеллекту или смежных с ними (распознавание образов, решение NP-трудных задач, обработка текста и т.д.), большинство задач являются грязными. Т.е. плохо поддающимися формальному описанию и не имеющими четких критериев правильности решения. Не знаю, как выкручиваются химики, а программистам редко удается порешать такие задачи, не запачкавшись. Программирование грязных задач тоже грязно, и здесь грязное — не значит плохое. Эта статья не о том, как сохранить чистоту и стерильность. Эта статья о том, как, вооружившись ломом мужеством и терпением, погрузиться в глубинные литосферные слои и выжить.

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

После небольшого перерыва мы вновь продолжаем серию вебинаров по QML и QtQuick, и на этот раз поговорим про состояния и переходы — один из важнейших моментов в построении пользовательских интерфейсов на QML.

Декларативный стиль языка QML направлен на то, чтобы избежать ошибок при построении интерфейса пользователя, которые вызываются некорректным переходом из одного состояния в другое. Для этого в QML есть встроенная поддержка для определения декларации состояний и переходов между ними, и машина состояний (state-machine), которая умеет эти переходы корректно осуществлять. Таким образом QML нам даёт формальную спецификацию интерфейса, надёжный способ организации логики приложения, гарантию покрытия всей функциональности и возможность связки переходов между состояниями с анимацией.

Внимательно посмотрев данный вебинар, вы научитесь работать с состояниями (states), условиями состояний и переходами между состояниями (transitions). Во второй половине видео вы узнаете о вероятных проблемах, связанных с использованием состояний и переходов, а также о возможных путях их решения.

Привет, хабр!

UPD: третья часть цикла.

Это вторая статья цикла про QScintilla. Первая здесь. Для начала хочу сказать огромное спасибо всем, кто вывел меня из кармоямы! А теперь можно начать. Что мы сегодня будем делать? Мы напишем лексер для Assembler'а! «В коробке» его нету — не беда, напишем сами! Процесс довольно длительный, поэтому я буду немного меньше расписывать и комментировать. Тем более я не знаю язык ассемблера, так что лексер будет до ужаса примитивный и будет разрисовывать только команды и комментарии.

Как сказал Гагарин — «Поехали!»

Дзэн Питона

Изучение культуры, которая окружает язык, приближает вас на шаг к лучшим программистам. Если вы всё еще не прочли «Zen of Python», то откройте интерпретатор Python и введите import this. Для каждого элемента в списке вы найдете пример здесь

Однажды моё внимание привлекло:

Преамбула

Доброго дня %user_name%. За годы накопленного опыта в сфере программирования у меня накопились некоторые наблюдения, заслуживающее того, что бы быть структурированными. Сегодня я поговорю о той части работы программистом где он соприкасается с необходимостью обучения. Постараюсь изложить некоторые неоднозначные принципы, а таких в программировании ой как много!

Примечание переводчика: перед прочтением этого поста рекомендую сначала ознакомиться с постом Вникаем в метаклассы Ruby.

Все рубисты знакомы с формальными определениями для include и extend. Вы делаете include модуля, чтобы добавить методы экземпляра класса, и extend — чтобы добавить методы класса. К сожалению, данные определения не совсем точны. Они не могут объяснить почему мы используем instance.extend(Module), чтобы добавить методы объекту. Разве не должны мы в этом случае использовать instance.include(Module)? Чтобы разобраться в этом вопросе, начнем с выяснения где же хранятся методы.