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

Почему тонкостям вычислений в условиях такой арифметики разработчики прикладных программ не уделяют внимание, вопрос. Рискну только предположить, что, по всей вероятности, сказывается привычка производить вычисления на калькуляторе… Во всяком случае, с завидной регулярностью «имею счастье» лицезреть, как коллеги по цеху наступают на одни и те же грабли. Этот материал нацелен на то, чтобы те самые «грабли» нейтрализовать.

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

Каждый программист старается писать хороший код. Читабельность — один из главных признаков такого кода. О ней написано достаточно много книг, но всё же в теме есть пробелы. Например, те самые книги сфокусированы больше на советах КАК написать читабельный код, а не на причинах того, почему один код является хорошо читабельным, а другой — нет. Книга говорит нам «используйте подходящие названия переменных» — но что делает одно название более подходящим, чем другое? Работает ли это для всех примеров подобного кода? Работает ли это для всех программистов, которым попадётся на глаза этот код? Как раз о последнем я и хотел бы поговорить чуть детальнее. Давайте погрузимся немного в человеческую психику. Наш мозг — главный наш инструмент, хорошо бы изучить специфику его работы.

В декабре прошлого года мы участвовали в хакатоне со своей платформой прототипирования. За отведенные два дня мы замахнулись с нуля разобраться с онлайн-кассой и её облачной экосистемой, а также сделать прототип сервиса — Маркетплейс. Как и ожидалось, мы потратили 80% времени на интеграцию с незнакомым устройством, а за оставшиеся 20% хорошо развлеклись и сделали всё остальное.

Честно, нас удивила простота входа в этот облачный мир, его масштабы (160 тысяч пользователей практически на старте), возможности и… дыры. В итоге у нас всё получилось, а компания-организатор, по их заявлениям, вот-вот стартует проект маркетплейса.

В этой статье я покажу как за 2-3 часа был сделан веб-сервис, интегрированный с облачными кассами и пригодный для обкатки на фокусной группе клиентов. Сам проект доступен для ознакомления и клонирования в виде исходников в github и онлайн версии.

Хотел бы поделиться с вами некоторыми советами и трюками, которые я использовал на этом примере.

Скачайте Swift Playground со всем кодом из этой статьи:



Codable представлен в Swift 4 с целью заменить старый NSCoding API. В отличие от NSCoding у Codable есть поддержка JSON первого класса, что делает его перспективным вариантом для использования API JSON.

Codable отлично подходит в качестве NSCoding. Если имеется необходимость кодировать или декодировать некоторые локальные данные, которые вы должны контролировать в полной мере, вы можете использовать преимущество автоматического кодирования и декодирования.

Вы наверняка это слышали: «Хороший код является самодокументированным».

Я больше 20 лет зарабатываю написанием кода, и слышал эту фразу чаще всего. Это клише.

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

Она истинна? Да.

Означает ли она, что вы никогда не должны комментировать код? Нет.

В этой статье мы рассмотрим разные аспекты комментирования кода.

Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.

Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.

В былые времена люди использовали \a для генерирования неприятных «гудков» из спикеров системных блоков. Это было особенно неудобно, если хотелось генерировать более сложные звуковые последовательности вроде 8-битной музыки. Поэтому Джонатан Найтингейл написал программу beep. Это была коротенькая и очень простая программа, позволявшая тонко настраивать звучание из спикера.

С появлением X-сервера всё стало куда сложнее.

Чтобы beep могла работать, пользователь должен был либо быть суперпользователем, либо являться владельцем текущего tty. То есть beep всегда будет работать у root-пользователя или у любого локального, но не будет работать у не-root удалённого пользователя. При этом любой терминал (например, xterm), подключённый к X-серверу, считается «удалённым», и поэтому beep работать не будет.

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

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

Но есть исключение, и вы уже догадались, о ком речь. Несчастные, презираемые, ненавидимые или игнорируемые большинством 1Сники.

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

Но большинство 1Сников, увы, не такие. Скромные, тихие, считающие свою «одинэсность» — постыдным недостатком, психическим или физическим заболеванием. Читая Хабр, они вынуждены скрывать свои «желтые трусы», чтобы не быть с позором изгнанными, оплеванными и поруганными.

Они читают о разработке игр, веб-приложений, машинном обучении, работе за рубежом, Google и Apple, и плачут. А потом отторгают, злятся, бросают читать, возвращаются в бухгалтерию… Но возвращаются снова и читают.

Публикация — для них.

В пятницу 6 апреля 2018 началась мощная атака на оборудование Cisco.

Много пишут о том, что главная причина, по которой эта атака успешна, это открытые во внешние сети сервисные порты Cisco Smart Install.

Эти порты открыты по умолчанию. А люди в массе своей оставляют то, что сконфигурировано/выбрано/настроено таким, каким оно было по умолчанию. Как видим, на примере этого случая, это касается не только домашних роутеров, но и серьёзного оборудования в крупных компаниях, где цена ошибки значительно выше.

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

Вы лишь можете заставить изменить эти значения с помощью каких либо ограничивающих использование приёмов. Чему многие будут не рады. «Защита от дурака» это один из примеров этих обязывающих ограничений.


Я хочу обратить внимание на корень самой уязвимости. В отчёте есть такая часть:

Привет, Хабр. Меня зовут Евгений Удодов, я сооснователь и технический директор компании Roistat. Хочу поделиться нашим опытом разработки большого и сложного продукта — системы аналитики.

TL;DR: Мы выложили на github наш Code Conventions и рассказали в статье о том, как его применять на практике.

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

За 4 года существования нашего проекта мы сделали больше 20 000 Pull Request’ов (далее PR) и под катом я расскажу, как же мы решили эти проблемы.

Пролог

— Ты, главное, не ссы! Держись меня, делай как я, и все будет чики-пуки.

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

— Коль, давай посерьезнее. — Жанна строго посмотрела на круглую самодовольную рожу. Потом перевела взгляд на новенького. — Сергей, не слушай этого старого коня. Борозды он, конечно, не испортит, но и целины не поднимет.

Сергею пришлось улыбнуться — все-таки начальник пошутил, и вроде не совсем безнадежно.

— Мы на тебя возлагаем большие надежды, Сережа. Николай у нас под завязку загружен текучкой — ее очень много. Мы понимаем, что действуем неэффективно, где-то что-то упускаем, используем устаревшие технологии и подходы… Но у нас реально нет времени остановиться, подумать, посмотреть, поучиться. Как писал Кови — наточить пилу.

Сергей понимающе покивал головой. Он не знал, кто такой Кови, но метафору понял.

— Ты — молодой, целеустремленный, не обремененный обязательствами и связями, амбициозный, и очень умный программист. У тебя за плечами очная Бауманка. Мы ждем от тебя новой струи свежего вохдуха, скачка в развитии наших систем, прорыва облачных технологий. Так, и только так!

— Спасибо, Жанна Ивановна. Я буду стараться.

— Никакого отчества, просто Жанна! Велкам в нашу команду, Сережа!

У кода есть мускулы. Правда-правда. Не веришь? Смотри:



Весь код, который выполняет реальную работу: производит вычисления, преобразует данные, проверяет условия и т. д. — это «мясо». «Мышцы» программы. Код, который отвечает за структуризацию — «сухожилия». То, с помощью чего мышцы крепятся к костям. То, благодаря чему каждый отдельный мускул остаётся самостоятельным, а не слипается в бесформенный фарш. А что тогда «кости»? Кости — это пусть будет архитектура программы.

Не так давно React позиционировал себя как "V in MVC". После этого коммита маркетинговый текст изменился, но суть осталась той же: React отвечает за отображение, разработчик — за все остальное, то есть, говоря в терминах MVC, за Model и Controller.

Одним из решений для управления Model (состоянием) вашего приложения стал Redux. Его появление мотивировано возросшей сложностью frontend-приложений, с которой не способен справиться MVC.

Главный Технический Императив Разработки ПО — управление сложностью

— Совершенный код

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

• состояние всего приложения хранится в одном месте
• единственный способ изменить состояние — отправка Action'ов
• все изменения происходят с помощью чистых функций

Смог ли Redux побороть возросшую сложность и было ли с чем бороться?

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

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

Фобии — это зло, как в жизни, так и в работе. Потому что предмет страха — выдуманный, а сам страх — настоящий. И последствия страхов вполне реальные.

В этой статье — истории реальных программистов и их профессиональных фобий, которые мешали им жить и работать в свое удовольствие. Люди реальные, имена вымышленные.

От переводчика

Всем привет! Я продолжаю серию переводов, в которой мы по косточкам разбираем, что такое Dependency Injection.

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

В сегодняшнем переводе речь пойдет о том, что собой представляет DI-контейнер, его функциях, преимуществах использования и отличии от фабрик.

От переводчика

Представляемый вашему вниманию перевод открывает серию статей от Jakob Jenkov, посвященных внедрению зависимостей, или DI. Примечательна серия тем, что в ней автор, анализируя понятия и практическое применение таких понятий как «зависимость», «внедрение зависимостей», «контейнер для внедрения зависимостей», сравнивая паттерны создания объектов, анализируя недостатки конкретных реализаций DI-контейнеров (например, Spring), рассказывает, как пришел к написанию собственного DI-контейнера. Таким образом, читателю предлагается познакомиться с довольно цельным взглядом на вопрос управления зависимостями в приложениях.

В данной статье сравнивается подход к настройке объектов изнутри и извне (DI). По смыслу настоящая статья продолжает статью Jakob Jenkov Understanding Dependencies, в которой дается определение самому понятию «зависимости» и их типам.

Регулярные выражения в Python от простого к сложному

Решил я давеча моим школьникам дать задачек на регулярные выражения для изучения. А к задачкам нужна какая-нибудь теория. И стал я искать хорошие тексты на русском. Пяток сносных нашёл, но всё не то. Что-то смято, что-то упущено. У этих текстов был не только фатальный недостаток. Мало картинок, мало примеров. И почти нет разумных задач. Ну неужели поиск IP-адреса — это самая частая задача для регулярных выражений? Вот и я думаю, что нет.
Про разницу (?:...) / (...) фиг найдёшь, а без этого знания в некоторых случаях можно только страдать.

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

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

От переводчика

Мы — внедрители. Мы должны внедрять, а не фантазировать!
(Рина Зеленая, к/ф «Девушка без адреса»)

К переводу этой статьи меня побудили две причины: 1) желание лучше разобраться с фреймворком Spring, 2) небольшое количество источников по теме на русском языке.

Краеугольный камень ООП — «внедрение зависимостей». Если описание процесса «внедрения» в целом, удовлетворительно, то объяснение понятия «зависимость» обычно оставляют за скобками. На мой взгляд, это существенное упущение.



Чтобы не фантазировать, а внедрять, нужно сначала разобраться с тем, что мы внедряем. И в этом нам может помочь лаконичная статья Jakob Jenkov «Understanding Dependencies». Она будет полезна не только тем, кто пишет на Java, но и тем, кто пишет на других языках и следит за качеством проектирования приложений.

UPD: Я перевел еще одну статью Jakob Jenkov о зависимостях. Читайте на Хабре перевод статьи Dependency Injection, которая открывает одноименную серию статей и по смыслу продолжает данную статью. В статьях серии рассматриваются такие понятия как Dependency, Dependency Injection (DI), DI-контейнеры.

Вы все пишите блистательно,
а я потом добавлю шероховатости.
х/ф Трамбо

Написать Java код не просто, а очень просто. Трудности начинаются, когда его запускают или, хуже того, если его требуется изменить. Открыв свой код двухлетней давности, каждый хотя бы раз задавался вопросом: кто же все это написал? Мы в Wrike разрабатываем продукт и делаем это уже более десяти лет. Подобные ситуации случались с нами неоднократно. За это время мы выработали ряд принципов в написании кода, которые помогают нам сделать его проще и нагляднее. Хотя в нашем подходе нет ничего экстраординарного, он во многом отличается от того, как принято писать код на Java. Тем не менее, кто-то может найти нечто полезное в нашем подходе и для себя.

Даже для самого что ни на есть начинающего разработчика (скорее, на которого и рассчитан данный очерк), надеюсь, не секрет, что в коде не должно присутствовать никаких т.н. «hardcoded»-значений и прочих всяких там «magic numbers». Почему – тоже, надеюсь, понятно, а если нет, то в Сети имеются десятки, а то и сотни статей на эту тему, а также написан классический труд. «Android Studio» (наверное, не во всех случаях, но все же) даже любит генерировать «warnings» на эту тему и предлагать выносить строки и т.д. в ресурсные файлы. «Xcode» (пока?) такими подсказками нас не балует, и разработчику приходится самостоятельно держать себя в узде или, скажем, получать по рукам от коллег после «code review».

Все это касается и используемых в приложении цветов.