Исполняем обязанности по получению сведений о своих бенефициарных владельцах

Небольшая вводная

Начиная с 21 декабря 2016 года вступили изменения в ФЗ РФ «О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма», касательно обязанности юридического лица по раскрытию информации о своих бенефициарных владельцах. В связи с этим, многие компании направляют запросы по цепочке владения с целью выяснения своих бенефициарных владельцев. Кто-то формирует запросы на бумаге, кто-то рассылает электронные письма.

На наш взгляд, надлежащим доказательством исполнения обязанности «знай своего бенефициарного владельца» является наличие письма на бумаге с отметкой об отправке/вручении. Данные письма в идеале должны готовиться не реже одного раза в год. Если в ведении юриста находится всего несколько компаний, то составление писем не составляет особого труда. Но, если компаний больше 3-х десятков, составление писем превращается в уничтожающую позитив рутину. Дело усугубляется тем, что реквизиты писем постоянно меняются: подписанты увольняются, компании перерегистрируются, меняя адреса. Все это надо учитывать. Как здесь могут помочь навыки программирования на python?

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

А для тех, кто зарегистрировался в качестве ИП, мы подготовили: 7 советов начинающему ИП, чтобы избежать проблем (что-то вы точно из этого не знаете)

Друзья, мы рады сообщить, что перевод всего гарвардского курса CS50 закончен.

Мы писали, что в курсе 24 серии, однако последние две оказались одной и той же лекцией (одна прочитана в Гарварде, а другая в Йеле), поэтому в списке переведённых лекций не 24, а 23.

Список лекций под катом.


Курс переведён и озвучен нашей студией по заказу JavaRush, и мы хотим сказать им огромное спасибо за поддержку!

Мне нужно сделать признание. До того, как я стал респектабельным разработчиком, работающим с такими современными языками, как C# и Java (и тем бурлящим хаосом, который известен нам под именем JavaScript), я был увлечённым фанатом невероятно популярного и неуклюжего Visual Basic.

Моя влюблённость была искренней. Ещё в детстве я учился программировать на языке BASIC. Но не просто на BASIC. Я начинал с потрясающей среды Microsoft под названием QuickBASIC на древней операционной системе DOS. Я всё ещё помню, как набирал белый текст на её бодром голубом фоне.


Для программирования в 1988 году QuickBASIC был волшебной штукой. Можно было писать код без громоздких номеров строк, отлавливать синтаксические ошибки в процессе набора и запускать программы прямиком из среды разработки без необходимости возни с командной строкой. Закончив программу, можно было делиться ею со своими друзьями при помощи вот этих ребят:


В наши дни QuickBASIC остался лишь ещё одной диковинкой из далёкого прошлого. Хотя так ли это? Новаторский проект под названием QB64 создал современную реплику QuickBASIC. Он запускается на Windows, MacOS и Linux, и не требует эмулятора. При запуске программы в QB64 среда выполняет хитрый трюк — сначала она транслирует код на BASIC в C++, а затем компилирует его.

Классический VB и эра Visual

QuickBASIC был впечатляющей средой для далёких дней текстовых компьютерных систем. Но всё изменилось, когда Microsoft выпустила Windows и погрузила пользователей PC в графический мир кнопок и кликов. Одновременно с выпуском компанией Microsoft Windows 3.0 (первой версии, которая добилась истинного успеха), был выпущен Visual Basic 1.0.

Кроме огромных репозиториев с источниками для подготовки к интервью, здесь много чего интересного

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

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

Первый подтверждённый случай коронавируса в Италии и Южной Корее примерно 20 января. Население — 60М в Италии, 51М — в Южной Корее.

На конец 11 марта 2020г. в Италии 12462 подтверждённых случае и 827 смертей, ~6.6%. В Южной Корее — 7755, 61, ~0.77%. (числа отсюда [1]).

В Италии ситуация хуже почти на порядок (в 8.5 раз). Но почему? Попробуем хотя бы частично разобраться.



Дисклеймер. Я — не медик и не биолог.

В рамках этого текста буду играть за математика с опытом биоинформатики.

Поэтому рассуждения могут оказаться не имеющими отношения к действительности. С другой стороны все факты будут подтверждены пруфлинками.

Если у вас есть факты с пруфлинками — жгите!

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

Не только содержание, но и структура текста должна быть осмысленна.

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

• Заголовок
• Суть статьи
  На основе этих нескольких предложений вместе с заголовком читатель должен понять, интересно ли ему читать эту статью дальше.
• Краткое изложение
  Здесь в максимально сжатом виде, тезисно, но с необходимой точностью и полнотой должна быть отражена суть данной статьи — от нескольких предложений до нескольких страниц. Кому-то, кто глубоко в теме этого может быть достаточно для понимания всей статьи. Но в любом случае читателю полезно представлять в самом общем виде, о чем эта статья, и какие выводы он получит в конце.
  
• Логика статьи
  Если статья длинная, содержит много разделов и сложную логику, то эта глава может быть также полезной. По сути это расширенное оглавление. Здесь кратко, на одной-двух страничках, излагается логика рассуждения, сухо, без деталей. Опять-таки, кому-то этого будет достаточно для того, чтобы все понять. Если сложно, то читатель может это пропустить (как оглавление) и читать дальше.
• Упрощенное изложение
  Если статья достаточно сложная, то многим было бы удобно сначала понять концептуально, что же хочет сказать автор. Поэтому неплохо сначала изложить все так, как если бы вы рассказывали студентам, упуская сложные доказательства, и, возможно, не столь формальным и строгим языком. Для очень многих такой уровень изложения может быть достаточным, и они остановятся здесь.
• Строгое изложение
  Здесь строго профессиональное изложение.
  

Содержание

• Что такое API
  
  • API — набор функций
  • Как составляется набор функций
  • При чем тут слово «интерфейс»
• Как вызывается API
  
  • Вызов API напрямую
  • Косвенный вызов API
• Что значит «Тестирование API»
• Резюме

Слово «API» мелькает в вакансиях даже для начинающих тестировщиков. То REST API, то SOAP API, то просто API. Что же это за зверь такой? Давайте разбираться!

— А зачем это мне? Я вообще-то web тестирую! Вот если пойду в автоматизацию, тогда да… Ну, еще это в enterprise тестируют, я слышал…

А вот и нет! Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.

Любая оплата идет через API платежной системы. Купил билет в кино? Маечку в онлайн-магазине? Книжку? Как только жмешь «оплатить», сайт соединяет тебя с платежной системой.

Но даже если у вас нет интеграции с другими системами, у вас всё равно есть API! Потому что система внутри себя тоже общается по api. И пока фронт-разработчик усиленно пилит GUI (графический интерфейс), вы можете:

• скучать в ожидании;
• проверять логику работы по API

Конечно, я за второй вариант! Так что давайте разбираться, что же такое API. Можно посмотреть видео на youtube, или прочитать дальше в виде статьи.

Что такое API

API (Application programming interface) — это контракт, который предоставляет программа. «Ко мне можно обращаться так и так, я обязуюсь делать то и это».

Если переводить на русский, это было бы слово «договор». Договор между двумя сторонами, как договор на покупку машины:

• мои обязанности — внести такую то сумму,
• обязанность продавца — дать машину.

Перевести можно, да. Но никто так не делает ¯\_(ツ)_/¯

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

Если порядок активации нейронов при попытке что-то вспомнить на 100% совпадает с порядком активации клеток в ходе запоминания, то точность воспроизведения информации будет тоже близка к 100%. Соответственно, чем больше ошибок в порядке возбуждения нейронов, тем менее точной будет восстановленная информация.

В первом номере Linux Journal было опубликовано интервью, взятое Робертом Янгом, первым издателем журнала (и, среди прочего, основателем Red Hat) у Линуса Торвальдса (автора ядра Linux). Мы решили, что будет интересно свести их снова вместе спустя 25 лет. Первое интервью можно найти по ссылке.

Роберт Янг: Повод связаться с тобой стал для меня большим удовольствием. Как ты, как семья? У тебя дети уже, наверное, колледж закончили. У нас с Нэнси три дочери, у всех всё нормально. У старшей, Зои, которой было 11 лет, когда мы с Марком запустили проект Red Hat, скоро родится второй – то есть, я уже дедушка.

Линус Торвальдс: Мои дети ещё не закончили колледж, хотя Патрисия (старшая) заканчивает в мае. Селеста (младшая) учится в последнем классе школы, поэтому месяцев через шесть наше гнездо опустеет.

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

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

Видеоадаптеры MDA и CGA

Обе модели были выпущены компанией IBM в 1981 году. MDA изначально ориентировался на деловую сферу и создавался под работу с текстом. Работая с нестандартными вертикальными и горизонтальными частотами, этот адаптер обеспечивал четкость изображения символов. В то же время CGA поддерживал только стандартные частоты и уступал в качестве выводимого на экран текста. Кстати в IBM PC можно было использовать одновременно оба адаптера.

Как бы вы руководили разработкой крупнейшего проекта с открытыми исходниками, в котором порядка 15 тыс. разработчиков и 222 компании вносят более 12 тыс. изменений между релизами или 7 / 8 правок каждый час? Чем пользуются создатель кернела Линус Торвальдс, мейнтейнер стабильной ветки Грег Кроа-Хартман (GKH) и другие товарищи, чтобы успешно координировать работу проекта и обеспечивать своевременный выход каждой новой версии?

Этим чудо-инструментом является текстовый клиент электронной почты: Mutt у GKH и Alpine у Линуса Торвальдса. Третий по рангу разработчик ядра Эндрю Мортон, также вовсю использует электронку для управления mm веткой.

With the wide variety of more “modern” development tools such as github, gerrit, and other methods of software development, why is the Linux kernel team still stuck in the 1990’s with ancient requirements of plain text email in order to get patches accepted? This talk will discuss just how the kernel development process works, why we rely on these “ancient” tools, and how they still work so much better than anything else.^[1]

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

Привет, хабровчане. Про kPHP от ВКонтакте уже многие успели прочитать и в прошлом топике, и где-то ещё, но деталей, конечно, пока было мало. Для удовлетворения собственного любопытства и интереса со стороны сообщества, мы обратились за комментариями к первоисточнику, то есть Павлу Дурову, который порекомендовал мне поговорить о kPHP с ребятами из команды — Олегом Илларионовым и Василием Бабичем, которые отвечали за перенос ВК на рельсы свежей разработки.

Первым делом я задал те вопросы, которые звучали в комментариях к анонсу: что с ООП, кто быстрее — слон или кит Java C# Go или kPHP, в каких проектах kPHP будет наиболее полезен и так далее. Кроме того, мы поговорили о планах развития и, немного, о других разработках и «кодовой» кухне ВК.

Приветствую.

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

Самая популярная и, пожалуй, самая удобная методика работы в ИТ сфере – это методология IT Infrastructure Library (ITIL). Она была разработана британской правительственной организацией для упорядочивания отношений с подрядчиками ИТ услуг. Первоначально библиотека ITIL состояла из 7 книг, из которых основными были «Предоставление услуг» и «Поддержка» (Service Delivery и Service Support). В них были описаны процессы, которые составляют ядро ITIL, в том числе Incident management.

Главное назначение Incident management – максимально быстрая ликвидация проблем в ИТ инфраструктуре – аварий, проблем с оборудованием и т.д. Для реализации процесса в организации и создается специальный отдел, который контактирует с сотрудниками и согласовывает ликвидацию проблем с ИТ подразделением. Этот отдел может называться Центр обслуживания пользователей (Service Desk) или Центр поддержки пользователей (Help Desk).

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

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

Как правило, язык C++ используют там, где требуется высокая скорость работы. Но на C++ без особых усилий можно получить код, работающий медленнее какого-нибудь Python/Ruby. Именно подобным кодом оперируют многочисленные сравнения Any-Lang vs C++.

Вообще, оптимизация бывает трех типов:

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

Специально заниматься оптимизацией готового кода следует только после того, как проект закончен и используется. Как правило, оптимизация потребуется только в небольшой части проекта. Поэтому сначала нужно найти места в коде, которые съедают большую часть процессорного времени. Ведь какой смысл ускорять код, пусть даже на 500%, если он отнимает только 1% машинного времени? И следует помнить, что, как правило, гораздо больший выигрыш в скорости дает оптимизация самих алгоритмов, а не кода. Именно про данный ее вид говорят: «преждевременная оптимизация — зло» (с).

Второй тип оптимизации — это изначальное проектирование кода с учетом требований к производительности. Такое проектирование не является ранней оптимизацией.

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