Компания Microsoft выпустила «Microsoft Application Inspector», кросс-платформенный опенсорсный (!) инструмент для анализа исходного кода.

Именно таким вопросом я задался, когда будучи простым физическим лицом и гражданином РФ, устроился на удалённую работу разработчиком ПО в одну иностранную компанию и начал получать заработную плату валютой из-за рубежа. Порывшись в Сети на предмет возможностей легализации своего дохода не нашёл чётких и точных ответов и руководств. Пришлось искать информацию самому. Результатами своих изысканий я и хочу поделиться со всеми.

Сразу пишу к чему пришёл в ходе изысканий:

1. ИП на ПСН
2. поступление оплаты за услуги по разработке ПО на счёт ИП в долларах США
3. основание для оплаты инвойс, сумма которого не превышает 200 000 руб.
4. инвойсы выставляются по-мере необходимости
5. ККТ не используется

То есть, спокойно работаю, в конце оговоренного периода формирую инвойс, в котором указываю согласованную с работодателем сумму не превышающую указанный порог, получаю деньги прямо на расчётный счёт, оплачиваю раз в год или в течение года патент и взносы в размере 54 000 рублей и больше не переживаю о том, что завтра злобные налоговики придут ко мне с повесткой и ужасными новостями (это была минутка юмора). В следующем году эта сумма подрастёт до 60 000 рублей за год.

Почему так? Какие могут быть ещё варианты? Чем плохи для меня Upwork, PayPal и Payoneer? Попробую ответить под катом. Кому интересны все эти детали, читаем дальше :-)

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

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

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

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

В данной статье вы встретите сразу два источника информации:

1. Полный курс по работе Garbage Collector на русском языке: CLRium #6 (текущий семинар здесь)
2. Перевод статьи из BOTR "Устройство сборщика мусора" от Маони Стевенс.

На прошлом внутреннем митапе Pyrus мы говорили о современных распределенных хранилищах, а Максим Нальский, CEO и основатель Pyrus, поделился первым впечатлением от FoundationDB. В этой статье рассказываем о технических нюансах, с которыми сталкиваешься при выборе технологии для масштабирования хранения структурированных данных.

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

Прошлой осенью мы объявили о том, что планируем расширить IT-команду с 48 до 250 человек. Сразу посыпались вопросы, которые по сути сводились к одному: зачем сети пиццерий 250 разработчиков? Откуда эта цифра? Поэтому в первом посте в нашем блоге хочу ответить именно на этот вопрос (и, конечно, на любые другие в комментах).

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

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

В один прекрасный день разные каналы в телеграмме начали кидать ссылку на крэкмишку от ЛК, Успешно выполнившие задание будут приглашены на собеседование!. После такого громкого заявления мне стало интересно, насколько сложным будет реверс. О том, как я решал этот таск можно почитать под катом (много картинок).

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

Для начинающих поясню, что миграция идет по такой схеме: источники → преобразование данных (отвечает ETL или шина) → приемник.

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

Здравствуйте! Хочу поделиться решением одной проблемы. Как запустить эмулятор на amd-шном процессоре на Windows 10, используя WHPX.

Эта статья — часть «Хроники архитектуры программного обеспечения», серии статей об архитектуре ПО. В них я пишу о том, что узнал об архитектуре программного обеспечения, что я думаю об этом и как использую знания. Содержание этой статьи может иметь больше смысла, если вы прочитаете предыдущие статьи в серии.

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

Но мне всегда казалось, что не всё очень хорошо там отражено, я просто не знал, как сделать это лучше. Речь об общем ядре.

Кроме того, возникло ещё несколько мыслей, которые я изложу в этой небольшой статье.

Эта статья — часть «Хроники архитектуры программного обеспечения», серии статей об архитектуре ПО. В них я пишу о том, что узнал об архитектуре программного обеспечения, что я думаю об этом и как использую знания. Содержание этой статьи может иметь больше смысла, если вы прочитаете предыдущие статьи в серии.

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

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

Продолжая серию статей о «подводных камнях» не могу обойти стороной System.Net.HttpClient, который очень часто используется на практике, но при этом имеет несколько серьезных проблем, которые могут быть сразу не видны.

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

Мне на глаза попался документ с правилами и рекомендациями по процессу ревью кода внутри компании. Я решил, что такой полезной информацией надо поделиться с внешним миром. С благословения автора я публикую работу.

Сегодня в нашей виртуальной студии один из самых известных дотнетчиков — Джеффри Рихтер.

В данный момент он — Partner Software Architect в Microsoft, работающий по направлению Distributed Cloud Apps & Storage. Иначе говоря, человек, который знает об Azure Storage всё.

F.A.Q.

Слишком много текста. О чём это всё? Чтобы вам было веселей читать, для этой статьи мы придумали более интересную вёрстку. Слева будут говорящие головы, а справа — текст. Если вам уныло листать до интересующей части, то в оглавлении есть анкерные ссылки. В ролях: Евгений phillennium Трифонов (нетехнические вопросы) Советы разработчикам по созданию компании Комбинирование разных видов деятельности Что читать, что изучать, как писать Олег olegchir Чирухин (технические вопросы) Зачем Рихтер изучает JS, Golang и Python Стоит ли продолжать писать на C++ Эволюция и будущее разработки на платформе Windows, .NET и вообще Захватит ли JavaScript мир, нужна ли типобезопасность Немного о пользе облачных провайдеров Что лучше иметь — личный самолет или личный вертолёт Как всё успевать Почему эта статья попала в хаб JavaScript? Только для тех, кому интересно мнение архитектора Azure относительно JS и его позиция в холиваре о типобезопасности. Этот холивар перетекает у нас из интервью в интервью, и конца ему не видно. Почему эта статья попала в хаб С++? Изначально Рихтер писал книги про C++. Только для тех, кому интересно мнение архитектора Azure относительно будущего и применимости C++

Джефф стал известен еще в начале 90-х, когда написал книгу о том, как программировать Windows 3.1. Его книга «Programming Applications for Microsoft Windows» стала классикой, позже выпускалась как «Windows via C/C++» и выдержала несколько изданий.

С появлением .NET он написал «CLR via C#» — тоже получилась классика, тоже несколько изданий. В то время он был одним из основателей компании Wintellect и, формально не будучи частью Microsoft, оказался более свободен в оценках. Чем и заработал репутацию крупного независимого эксперта по Windows. Это человек-легенда уровня Чарльза Петцольда и Дона Бокса.

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



Вторая часть

У разработчика, который впервые столкнулся с генерированием электронных писем, практически нет шансов написать приложение, которое будет делать это корректно. Около 40 % писем, генерируемых корпоративными приложениями, имеют те или иные нарушения стандартов, и, как следствие, проблемы с доставкой и отображением. На это есть причины: электронная почта технически гораздо сложнее, чем веб, работа почты регулируется несколькими сотнями стандартов и несчетным количеством общепринятых (и не очень) практик, а почтовые клиенты отличаются разнообразием и непредсказуемостью. Тестирование может заметно улучшить ситуацию, но материалов, посвященных тестированию почты, практически нет.

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

• Какие бывают электронные письма
• Кто участвует в процессе тестирования и контроля
• Почтовое сообщение и почтовый транспорт
• Интерфейс почтовой инфраструктуры и границы тестируемого приложения
• Определение тестируемых параметров
• Типичная структура генерирующего приложения
• Что и когда тестировать
  
  1. Инфраструктура доставки
  2. Генерирующее приложение
  3. Структурный и вёрсточный шаблоны письма
• Базовые требования при проверке инфраструктуры
• Требования к авторизации
• Проверка генерирующего приложения
  
  • Требования к почтовым адресам
  • Требования к заголовкам писем
  • Требования к структуре письма
  • Требования к URI
  • Требования к вёрстке письма
• Проведение сплит-тестов

 
Участниками проекта hashcat обнаружен новый вектор атаки на беспроводной стандарт WPA2, не требующий классического перехвата "рукопожатия" между клиентом и точкой доступа. Данная уязвимость выявлена в рамках исследования потенциальных проблем безопасности нового протокола WPA3.

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

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

Для начала, давайте взглянем на картину в целом. Мы обратили внимание, что чем меньше компания по числу сотрудников, тем выше оценки ей ставят. Поэтому, сравнивать компании друг с другом по оценкам имеет смысл как минимум в своей «весовой» группе.

Хабр, привет! Это транскрипция доклада Артема ximaera Гавриченкова, прочитанного им на BackendConf 2018 в рамках прошедшего фестиваля РИТ++.

— Здравствуйте!

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

Это (под катом) заголовок одного из блогов, в интернете вы могли таких заголовков видеть очень много. В том посте написано, что HTTP/2 — это не какое-то отдаленное будущее, это наше настоящее; это современный протокол, разработанный Google и сотнями профессионалов из многих продвинутых компаний, выпущенный IETF в качестве RFC в далеком 2015 году, то есть уже 3 года назад.

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