Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Привет, Хабр!
В этой статье мы расскажем, как построен процесс разработки платформы «1С:Предприятие», как мы работаем над обеспечением качества, и поделимся уроками, которые получили, создавая один из самых больших российских программных комплексов.

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

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

Петя — опытный программист. Получив постановку, он ищет, нет ли исходного кода, решавшего аналогичную задачу. Пару дней Петя проводит, читая материалы и разбираясь в чужих модулях, а на третий — запускает свое решение, основанное на уже существующем коде. В нем есть пара незначительных ошибок, которые удается быстро исправить. Ура! Все работает так, как нужно, уже на третий день.

Как найти нужный вам кусок исходного кода? Как его понять? А главное — зачем все это делать? В поиске ответов на эти вопросы добро пожаловать под кат.

Многие боятся переходить с «мускуля» на «посгрес» из-за того, что лишь смутно понимают, что это даст. Некоторых останавливает мысль, что наверно Postgres — это слишком сложная база и требует обучения. А также, что возможно чего-то придется лишиться в связи с переходом. Попробую немного прояснить ситуацию.

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

Одна из таких финансово-расчетных систем получила название «Хавала». Она зародилась в Индостане задолго до появления банковской системы западного образца (по разным оценкам, она работала уже в 8 веке), и до сих пор используется многими гражданами стран Среднего Востока, Африки и Азии в качестве альтернативного инструмента расчетов.

1. Вступление

Сталкиваясь с необходимостью контролировать работу других программистов, начинаешь понимать, что, помимо вещей, которым люди учатся достаточно легко и быстро, находятся проблемы, для устранения которых требуется существенное время.

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

Но когда дело доходит собственно до кода, все становится гораздо менее однозначно. Да, можно указать на слабые места, можно даже объяснить, что с ними не так. И в следующий раз получить ревью с абсолютно новым набором проблем.

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

Говоря о базовых знаниях, надо отметить, что умение писать красивый профессиональный код — это то, что по тем или иным причинам, в эти базовые знания категорически не входит. Вместо этого, в соответствующих заведениях, а также в книжках, нам рассказывают про алгоритмы, языки, принципы ООП, паттерны дизайна…

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!

Как известно, в xUnit-фреймворках, простейший test-case состоит из последовательности вызовов SetUp, TestSomething, TearDown. И довольно часто в unit-тестировании требуется подготовить какие-то ресурсы перед основными тестами. Типичный пример этого — соединение с базой данных. И логика подсказывает нам, что было бы весьма затратно, запуская несколько тестов, перед каждым устанавливать соединение с БД в SetUp, и отключаться в TearDown.


Схема вызовов будет такая:

-- TTestDB1.SetUp
---- TTestDB1.TestDB1_1
-- TTestDB1.TearDown
-- TTestDB1.SetUp
---- TTestDB1.TestDB1_2
-- TTestDB1.TearDown

К тому же с БД может статься, что перед тем, как к БД подключиться, её нужно создать с требуемой структурой.

Для решения такой задачи в dUnit есть класс TTestSetup (описан в модуле TTestExtensions).

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

Начало

Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:

10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)

Рубрика «Как работают профессионалы» нашла еще одного высококлассного специалиста на рынке информационных технологий и знакомит читателей «Мегамозга» с его рабочими привычками.

Знакомьтесь – Даниил Трабун, главный редактор журнала «Афиша».

Тема обработки ошибок сложна и неоднозначна. До сих пор нет какого-то оптимального подхода или группы подходов к этой проблеме. Все они страдают от тех или иных недостатков. В этой статье я хотел бы поделиться своими мыслями на эту тему, и что не менее важно, почерпнуть новые знания в комментариях.

Код в статье приводится на scala, однако рассматриваемый подход может быть реализован на многих других языках (c++ с помощью макросов, java с помощью JetBrains MPS и т.д.). Наиболее близким аналогом рассматриваемого подхода является способ обработки ошибок в haskell.

^{Капитан Немо у штурвала «Наутилуса»}

Индексы — один из самых мощных инструментов в реляционных базах данных. Мы используем их, когда нужно быстро найти какие-то значения, когда объединяем базы данных, когда нужно ускорить работу SQL-операторов и т.д. Но что представляют собой индексы? И как они помогают ускорять поиск по БД? Для ответа на эти вопросы я изучил исходный код PostgreSQL, отследив, как происходит поиск индекса для простого строкового значения. Я ожидал найти сложные алгоритмы и эффективные структуры данных. И нашёл.

Здесь я расскажу о том, как устроены индексы и как они работают. Однако я не ожидал, что в их основе лежит информатика. В понимании подноготной индексов также помогли комментарии в коде, объясняющие не только как работает Postgres, но и почему он так работает.

Преамбула

Пару лет назад я и мои сотрудники столкнулись с проблемой сопровождения большого количества аналогичных БД на удаленных филиалах. Удалены они иногда на тысячи километров, а объемы исчислялись гигабайтами – что не позволяло использовать какое-либо зеркалирование серверов. Осложнялась ситуация мелкими отличиями, т.е. 95% бизнес-логики филиалов совпадало, но было ещё 5%, которые сильно мешали и ни о какой автоматической обработке группы филиалов не было и речи.

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

В топике рассматривается еще одна простая система версионирования структуры БД, а также ИМХО, почему нам не подходят другие.

Разминка

Прошло 23 года с тех пор, как я последний раз писал себе программы для тренировок. Несколько листов в тетради с карандашными рисунками, примечаниями и цифрами. Я начал их составлять после травмы поясницы, полученной по собственной глупости и незнанию, в небольшой «деревенской» качалке рядом с Загорской ГАЭС. Тот лишний блин к поднимаемому весу отзывается болью в моей спине и по сей день. Он заставляет меня, при любых обстоятельствах, поддерживать физическую форму. Так мы и живем, боль ждет когда ослабеет мышечный корсет, а я не даю ей этого шанса.

Многое, очень многое изменилось за эти годы, но люди по прежнему «качают железо» и делают одни и те-же ошибки. Я пишу для них. Может кому и пригодится…

Я, как и вы, знаю, что Джеймс Гослинг — великий человек, гигант, такой же, как Керниган, Ричи и Страуструп — начал разработку нового языка Oak 24 года назад. Я так же, как и вы, знаю, что активная жизнь нового языка началась 19 лет назад, когда в Интернете появилась его первая официальная версия от Sun Microsystems, и все мировые софтверные разработчики начали приобретать лицензии на Java 1.0. Но я праздную именно 20-летие Java. Возможно, я сентиментален, но для меня Java — это Java, а не какой-нибудь дуб. И для меня важно, что язык Java получил свое настоящее имя именно 20 лет назад. В честь вот этой вот чашечки кофе:

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



Попробуем разобраться, почему JPEG 2000, JPEG-XR и WebP все еще пасут задних, и действительно ли они такие классные, как заявлено.

Доброго дня, Geektimes. Мы продолжаем серию постов о легальном контенте в сети. В прошлый раз речь шла о музыкальных сервисах, сегодня же в прицеле нашего внимания ресурсы с сериалами и кино. Безусловно, уж чем-чем, а ресурсами с кино и сериалами интернет богат. Даже чересчур. Но много ли среди них порталов с легально размещённым контентом? Вряд ли таковых наберется хотя бы половина из первых нескольких десятков ссылок в выдаче любого поисковика по запросам вроде «бесплатные лицензионные фильмы».



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

Всем привет!

Бывало ли у вас такое, что ставите файл на закачку, и скорость медленно, но верно возрастает, затем, в какой-то момент, резко снижается, затем опять возрастает? Закачка файла в один поток не обеспечивает полную скорость канала? Запускаете торрент-клиент, и пинг в игре сильно прыгает? Используете 3G-модем (или другую линию с относительно большой потерей пакетов) и не можете это терпеть?
Наверняка вы винили во всем ваш роутер, либо обвиняли своего провайдера в кривой настройке шейпера? Это влияет, но виноваты не они.
Итак, встречайте:

TCP Congestion Control, или TCP Congestion Avoidance Algorithm.