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

• Собираем все данные по портфелю и по всем операциям через Tinkoff API.

• Строим огромную Excel таблицу со всеми данными.

• Узнаём, сколько комиссий и налогов с нас уже содрали и что нам останется при выводе.

• Пытаемся понять, что нам с этим делать.

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

На конференции DotNext Джон Скит поговорил о сложностях, связанных с написанием такого кода. Почему даже подход «просто храните всё в UTC» может приводить к ошибке, и пользователь может опоздать на встречу, правильно сохранённую в UTC?

А также говорил о Noda Time — созданном им инструменте для работы с датой и временем в .NET. Но доклад будет полезен, даже если вы не можете или не хотите использовать Noda Time.

Если хотите, можете посмотреть видео доклада в оригинале — запись под катом. А ещё мы подготовили для вас расшифровку. Далее — повествование от лица спикера.

Что такое CI

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

Если вы не знаете как настроить CI в своем проекте, я приглашаю вас "под кат"

Всем привет! Давно хотел и наконец написал небольшую книжку — бодрое пособие по своей профессиональной области: актуальным подходам к разметке интерфейсов, экранному дизайну и доступности. Она о моем оригинальном подходе к созданию GUI, препроцессорам CSS (для объективности, немного и об альтернативных подходах), и его эффективном практическом использовании с javascript и популярными реактивными компонентными фреймворками Vue и React. Материал представлен аккуратно последовательно, но безумно интенсивно и динамично — ничего лишнего или даже слишком подробного — для того чтобы увлеченный и подготовленный читатель не потерял интереса и «проглотил на одном дыхании». С другой стороны, текст, достаточно сложный ближе к концу, и на всем протяжении — густо насыщенный идеями, ссылками на технологии и подходы — поэтому, очевидно, будет «на вырост» начинающим. Но, в любом случае, как и если вы только начали интересоваться данной тематикой, так и если уже давно занимаетесь веб-дизайном, версткой и программированием фронтенда — вам может быть полезно на него взглянуть.

Ищем совпадение по шаблону

const testString = 'My test string'
const testRegex = /string/
testRegex.test(testString) // true

Ищем совпадение по нескольким шаблонам

const regex = /yes|no|maybe/

Игнорируем регистр

const caseInsensitiveRegex = /ignore case/i
const testString = 'We use the i flag to iGnOrE CasE'
caseInsensitiveRegex.test(testString) // true

Извлекаем первое совпадение в переменную

const match = 'Hello World!'.match(/hello/i) // 'Hello'

Первый квартал 2020 года я провел за подготовкой к экзамену OSCP. Поиск информации в Google и множество «слепых» попыток отнимали у меня все свободное время. Особенно непросто оказалось разобраться в механизмах повышения привилегий. Курс PWK уделяет этой теме большое внимание, однако методических материалов всегда недостаточно. В Интернете есть куча мануалов с полезными командами, но я не сторонник слепого следования рекомендациям без понимания, к чему это приведет.

Мне хочется поделиться с вами тем, что удалось узнать за время подготовки и успешной сдачи экзамена (включая периодические набеги на Hack The Box). Я испытывал сильнейшее ощущение благодарности к каждой крупице информации, которая помогала мне пройти путь Try Harder более осознанно, сейчас мое время отдать должное комьюнити.

Я хочу дать вам мануал по повышению привилегий в OS Linux, включающий в себя разбор наиболее частых векторов и смежных фишек, которые вам обязательно пригодятся. Зачастую сами механизмы повышения привилегий достаточно несложные, трудности возникают при структурировании и анализе информации. Поэтому я решил начать с «обзорной экскурсии» и далее рассматривать каждый вектор в отдельной статье. Надеюсь, я сэкономлю вам время на изучение темы.

Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.

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

На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).

Ее основными тезисами были:

• GitFlow противоречит тезису "ветки должны быть короткоживущими".
  Это важно, потому что чем меньше живет ветка — тем меньше шанс конфликтов (не только git, но и логических)
• GitFlow препятствует rebase-ам, чтобы сохранить merge-коммиты.
  Да, их можно сохранять и при ребейзах, но команды Git Flow не делают этого.
• GitFlow отрицает подход Contunious Delivery, считая, что каждый акт Delivery должен совершаться релиз-инженером, да и в целом можно увидеть, что он ориентирован только на долгий релизный цикл.
• GitFlow не дружит с микросервисами поверх мультирепозиториев (впрочем, тут вообще мало что подходит, это идея, которая всегда плохо заканчивается)

• Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.

  
  

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

  
  

Так что делать-то?