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

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

Оглавление

Предисловие
1. Настройка git
....1.1 Конфигурационные файлы
....1.2 Настройки по умолчанию
....1.3 Псевдонимы (aliases)
2. Основы git
....2.1 Создание репозитория
....2.2 Состояние файлов
....2.3 Работа с индексом
....2.4 Работа с коммитами
....2.5 Просмотр истории
....2.6 Работа с удалённым репозиторием
3. Ветвление в git
....3.1 Базовые операций
....3.2 Слияние веток
....3.3 Rerere
4. Указатели в git
....4.1 Перемещение указателей
5. Рекомендуемая литература

Предисловие

Git — самая популярная распределённая система контроля версиями.[1][2]

Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).

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

И я намеренно не пишу, для кого предназначен этот план подготовки: для senior, middle или junior разработчика — все зависит от конкретной вакансии и от требований работодателя. Поэтому опирайтесь на этот план, но фильтруйте и в то же время не воспринимайте его как исчерпывающее руководство.

1. Java core. Здесь можно ориентироваться например на книгу «OCP: Oracle Certified Professional Java SE 8 Programmer II Study Guide: Exam 1Z0-809» для подготовки к Java сертификации уровня Professional. Есть подобная книга «OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808» для уровня Associate — на нее тоже можно взглянуть. Пройдитесь по оглавлению и выделите для себя, что можно повторить. Конечно же, не стоит пускаться во все тяжкие и читать книгу от корки до корки — многие темы из этой книги можно обойти стороной, например форматирование дат. Выделите самое основное. Например для меня это были следующие темы: коллекции (стандартные вопросы «Как устроена HashMap?» или «Чем отличается LinkedList от ArrayList?» все также часто задают на собеседованиях), дженерики, функциональные интерфейсы, многопоточность (тут тоже фильтруйте — не нужны вам cyclic barrier и fork join framework).
   Также не забывайте проецировать знания на свой опыт. Например, когда вам приходилось использовать многопоточное программирование? Какие проблемы вы решали? Какие блокировки использовали?
   
2. Многопоточность.

В последнее десятилетие мы успешно пользовались тем, что Go обрабатывает ошибки как значения. Хотя в стандартной библиотеке была минимальная поддержка ошибок: лишь функции errors.New и fmt.Errorf, которые генерируют ошибку, содержащую только сообщение — встроенный интерфейс позволяет Go-программистам добавлять любую информацию. Нужен лишь тип, реализующий метод Error:

type QueryError struct {
    Query string
    Err   error
}

func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }

В этой статье хочу поделится нашими c SergeyMaslov наработками решения типовых задач с использованием микросервисной архитектуры на примере задачи «создание блога» (в надежде, что читатель представляет как устроен блог и это не должно вызывать вопросов по функциональности:)

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

Теперь пришла очередь API Gateway или API GW.

В нашем c ptimofeev API GW мы реализуем следующие функции:

• Конвертация REST запросов в gRPC запросы и наоборот.
• Логирование запросов.
• Аутентификация запросов.
• Присвоение каждому запросу Trace ID для дальнейшей передачи его между микросервисами по всей цепочке выполнения запроса.

Для реализации API необходимо провести большую работу. Чрезмерное планирование может стать пустой тратой сил, а его недостаток приводит к катастрофическим последствиям. В этой книге вы получите решения, которые позволят вам распределить необходимые ресурсы и достичь требуемого уровня эффективности за оптимальное время. Как соблюсти баланс гибкости и производительности, сохранив надёжность и простоту настройки? Четыре эксперта из Академии API объясняют разработчикам ПО, руководителям продуктов и проектов, как максимально увеличить ценность их API, управляя интерфейсами как продуктами с непрерывным жизненным циклом.

Материал книги основан на наших (Мехди Меджуи, Эрик Уайлд, Ронни Митра, Майк Амундсен) коллективных знаниях, полученных за много лет создания, разработки и улучшения API — как своих, так и чужих. В ней изложен весь наш опыт. Мы определили два ключевых фактора для эффективной разработки API: необходимость продуктоориентированного подхода и формирование правильной команды. Мы также определили три важных фактора для управления этой работой: руководство, развитие продукта и разработка системы API.

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

Источник: Proofpoint

Наборы эксплоитов и известные уязвимости ПО применяются для кибератак очень редко. На самом деле, более 99% успешных атак производится с участием жертвы. Цель должна собственноручно открыть файл, запустить макрос, нажать на ссылку или выполнить какое-то другое действие. Такова статистика из последнего отчёта от компании Proofpoint.

Современные атаки фокусируются не на инфраструктуре, а на конкретных людях. Специалисты даже выделяют особый тип пользователей, представляющих максимальную угрозу для любой организации — так называемые VAP-пользователи (Very Attacked People), по аналогии с VIP-персонами. Хакеры их очень ценят.

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

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



Меня зовут Катя Гаврилова, я основатель рекрутингового агентства DigitalHR. Однажды я выступала на Saint TeamLead Conf в 2018 году, и мой доклад «Роль тимлида в рекрутинге» попал в топ-5 лучших. А уже на Moscow TeamLead Conf доклад «Мало опыта — много собеседований: как проводить интервью, чтобы от вас не скрывали правду» не прошел в топ, но я до сих пор получаю на него хорошие отзывы от разработчиков, поэтому решила поделиться его версией в текстовом варианте. Целевая аудитория — тимлиды и CTO, которые недавно стали подбирать сотрудников к себе в команду.

Источник

Обработка ошибок в любой разработке играет важнейшую роль. В программе может пойти не так практически всё: пользователь введёт некорректные данные, или они могут прийти такими по http, или мы ошиблись при написании сериализации/десериализации и в процессе обработки программа падает с ошибкой. Да может банально закончится место на диске.

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

Допустим нам нужно скопировать всё из папки /source в папку /target.

Привет! Меня зовут Соснин Илья. Я работаю в Lamoda Android разработчиком. Крашу кнопочки, прогаю списочки и, к сожалению, пишу аналитику…

Lamoda — это Data Driven Company, в которой все решения принимаются на основе поведения пользователей. Сначала мы наблюдаем и только потом делаем выводы. Поэтому несложно догадаться, что аналитика у нас есть, и она нам очень нужна.

В расшифровке моего доклада митапа Mosdroid #18 Argon я расскажу, как устроен наш SDK и почему рефлексия — это не всегда плохо. А также отвечу на главный вопрос этой темы: «Как внедрить аналитику и не сломать приложение?».

Для начала задам один простой вопрос: “Как вы думаете, сколько у нас установок в Google play?”.

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

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

Цель: узнать о технологиях и новинках в области работы с веб-API и, конечно же, как все это реализовано в рамках Pornhub. Наслаждайтесь!

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

На прошлой неделе я рассказал, как устроена активация Яндекс.Станции через звук. Оказалось, что пароль от WiFi передаётся в открытом виде. Я размышлял, зачем вообще нужно было делать активацию так, а не каким-то отлаженным способом.

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



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

Python — красивый и местами загадочный язык. И даже зная его весьма неплохо, рано или поздно находишь для себя нечто такое, что раньше не использовал. Этот пост отражает некоторые детали языка, на которые многие не обращают внимание. Сразу скажу: многие примеры являются непрактичными, но, оттого, не менее интересными. Так же, многие примеры демонстрируют unpythonic стиль, но я и не претендую на новые стандарты — я просто хочу показать, что можно делать вот так.

Введение

Добрый день, хабровчане. Решал я тут давеча тестовое задание на вакансию QA Lead для одной финтех компании. Первая задача, составить тест-план с полным чек-листом и примерами тест-кейсов для проверки электрического чайника, решается тривиально:

• ГОСТ 7400-81. Электрочайники и электросамовары бытовые. Технические условия (с Изменениями N 1-8)
• ГОСТ IEC 60335-1-2015 Бытовые и аналогичные электрические приборы. Безопасность. Часть 1. Общие требования
  Лучшего тест-плана с полным чек-листом придумать сложно.

А вот вторая часть оказалась вопросом: “Существуют ли какие-то проблемы, общие для всех тестировщиков, мешающие работать с большей эффективностью?”.

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

В предыдущей публикации мы рассмотрели основные понятия и парадигму информационной безопасности, а сейчас перейдем к анализу российского и международного законодательства, регулирующего различные аспекты защиты данных, поскольку без знания законодательных норм, регулирующих соответствующие области деятельности компании, корректно выстроить систему управления риск- и бизнес-ориентированной информационной безопасностью невозможно. Штрафные санкции, а также репутационный ущерб от несоответствия законодательным нормам могут внести существенную коррективу в планы функционирования и развития организации: мы знаем, что, например, невыполнение норм защиты информации в национальной платежной системе может обернуться отзывом лицензии у финансовой организации, а несоответствие требованиям по месту первичного сбора и обработки персональных данных может привести к блокировке доступа к веб-сайту компании. Невыполнение же норм безопасности критической информационной инфраструктуры вообще может обернуться лишением свободы на срок до 10 лет. Разумеется, применимых законов и норм – огромное количество, поэтому в этой и двух последующих статьях сосредоточимся на защите персональных данных, защите объектов критической информационной инфраструктуры и информационной безопасности финансовых организаций.

Итак, в сегодняшней серии – персональные данные, поехали!

И снова здравствуйте! В преддверии старта курса «Разработчик Python» подготовили для вас небольшой авторский материал о связных списках на Python.

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

---

В прошлом посте мы рассказывали о том, как и почему мы в Acronis делаем аннотации к микросервисам, и обещали поделиться своей практикой применения единого формата API для всей платформы Acronis Cyber Platform. Сегодня мы расскажем про свой опыт статических проверок аннотаций – aka первый шаг на пути внедрения аннотаций в компании.

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

• на личном уровне подталкивают к прокастинации;
• в стартапе по мере его успеха и роста приводят к потере прежней творческой «внутренней атмосферы» и нарастанию бюрократии;
• в больших компаниях приводят к «иерархическому регрессу».

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

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