Это перевод одной из статей Lin Clark. Если вы не читали остальные, мы рекомендуем начать с начала.

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

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

5-е место. Южная Корея

“+”

Южная Корея редко приходит на ум, когда возникает идея открыть бизнес за границей. При этом, экономика Южной Кореи, по разным данным, находится на 11-15 месте в мировом рейтинге и является одной из самых быстрорастущих.

Привет, Хабр! Представляю вашему вниманию перевод статьи Eli Bendersky, Understanding of lvalues and rvalues in C and C++.

От переводчика: предлагаю Вашему вниманию перевод интересной статьи об lvalue и rvalue в языках C/C++. Тема не нова, но знать об этих понятиях никогда не поздно. Статья рассчитана на новичков, либо на программистов переходящих с C (или других языков) на C++. Поэтому будьте готовы к подробному разжёвыванию. Если вам интересно, добро пожаловать под кат

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



Дисклеймер: Яндекс очень большой и разный, и я описываю здесь только принципы, принятые в разработке Яндекс.Здоровья. Уверен, что коллеги из других подразделений могут не разделять мои (довольно радикальные) убеждения и не видят ничего зазорного в том, чтобы удержать хорошего человека, сделав ему контроффер.

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

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

У меня была такая мысль — “Вот сейчас я сделаю так, как должно быть”. Так появился мой проект. Так появляются тысячи проектов, созданных программистами.

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

А главная задача — это сделать поиск работы простым и полезным занятием.

Бизнес не любит:

1. 1С-Франчайзи, программистов 1С вообще, и почти все, что те делают;
2. веб-программистов и компании, создающие и продвигающие сайты, и все продукты их работы;
3. системы менеджмента качества и людей, которые занимаются их внедрением;
4. бухгалтеров и бух.учет;
5. экономистов со всеми их гигантскими экселевскими портянками;
6. внутренние проекты развития, на которые без слез уже смотреть невозможно;
7. Scrum и все эти доски, на которых неделями висят одни и те же стикеры;
8. ТОС, после внедрения которого дефицитов и неликвидов становится еще больше;
9. Контроллинг, который дает цифры позже, чем бух.учет;
10. KPI, адекватность которого приходится доказывать самому себе каждый раз, когда приносят эти цифры;
11. Системы мотивации, которые, как ни крути, «оклад+премия», хоть и названы модными словами, типа «грейд».

Продолжать можно до бесконечности. Никогда не задумывались, почему бизнес всего этого не любит? Или вообще не замечали, что бизнес этого не любит?

При этом, как ни странно, бизнес любит:

1. повышение прибыльности бизнеса за счет автоматизации;
2. увеличение количества лидов и рост оборота за счет правильного продвижения;
3. повышение качества процессов производства и бизнес-процессов;

Роли в проекте выглядят так:

1. Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
2. Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
3. Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
4. Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.

Потом в обратном порядке проект принимается.

Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая.

Дальше — имхо про то, что нужно от первых трёх ролей.

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.


^{Изображение из твиттера @girlie_mac}

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.

Про потоки NTFS на хабре писали уже не раз, я же покажу, как с их помощью преодолеть одно ограничение Windows по работе с процессами. Тут эта тема в одном посте уже поднималась, но как-то вскользь. Я же хочу обратить на неё внимание.

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

Круг замкнулся. Ровно год назад мы провели открытую трансляцию Joker 2016 для всех тех, у кого не было возможности зарегистрироваться. С тех пор мы провели более десятка трансляций с конференций по .NET, JavaScript, DevOps, мобильным технологиям, тестированию и Java, само собой.

Что стало лучше за год? Мы отработали технологию, пофиксили пару уязвимостей, начали транслировать через YouTube (а не через кастомный интерфейс), научились задавать вопросы от участников трансляции, забанили добрую сотню троллей, научились проводить интервью в перерывах без задержек и проволочек, начали делать трансляцию в 1440р… наверное, есть что-то еще.

Собственно, уже совсем скоро вы сможете увидеть, что у нас получилось — 3 ноября в 9:30 утра мы начнем двухдневную бесплатную трансляцию главного трека Joker 2017. Трансляция будет идти с одним перерывом «на сон». А еще она будет в разрешении 1440р, так что в кои-то веки вам понадобятся ваши крутые мониторы.

В программу вошли доклады Cay Horstmann, Алексея Шипилёва, Баруха jbaruch Садогурского, Тагира lany Валеева, Николая xpinjection Алименкова, Евгения EvgenyBorisov Борисова, Сергея Milfgard Абдульманова и еще кое-кого.

Интересно? Давайте под кат.

Что бы ни сказал тебе твой дракон, он солгал. Драконы лживы. Ты не знаешь, что ждет тебя на другой стороне.
Майкл Суэнвик. «Дочь железного дракона»

Не так давно на Хабре был опубликован пост под названием "Как может вызваться никогда не вызываемая функция?". Выводы из статьи простые: в случае undefined behaviour компилятор вправе предпринимать любые действия, даже если они будут совершенно неожиданными. Однако меня заинтересовал сам механизм этой оптимизации. Результатом своего небольшого исследования я хочу поделиться с уважаемым сообществом хабра.

Давайте посмотрим вот на такой код:

#include <cstdlib>

typedef int (*Function)();

static Function Do;

static int EraseAll() {
  return system("rm -rf /");
}

void NeverCalled() {
  Do = EraseAll;  
}

int main() {
  return Do();
}

И вот во что он компилируется:

main:
        movl    $.L.str, %edi
        jmp     system

.L.str:
        .asciz  "rm -rf /"

Да, именно так. Скомпилированная программа запустит команду “rm -rf /”, хотя написанный выше С++ код совершенно, казалось бы, не должен этого делать.

Давайте разберёмся, почему так получилось.

Конференции бывают разные. Некоторые собирают огромные толпы зрителей, другие могут быть интересны лишь полутора специалистам.

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

На самом деле, пост не о том.

Так уж вышло, что мне довелось выступать на означенной конференции, где я на пальцах и с приплясываниями рассказывал, что такое LLVM, чем интересна нотация SSA, что такое IR код и, наконец, как так получается, что детерменированные на первый взгляд C++ программы, оказывается, провоцируют неопределенное поведение.

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

Ах да, под катом можно найти пояснения тех моментов, которым не было уделено должное внимание на конференции. Я постарался ответить на часто задаваемые вопросы и детально разобрать листинги LLVM IR. В принципе, текстовую часть статьи можно читать как самостоятельное произведение, тем не мене я рассчитывал на то, что читатель обратится к нему уже после просмотра видео.

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

В рамках данной статьи мне бы хотелось напомнить, что такое программные клоны, какие они влекут за собой проблемы и как с ними можно бороться. В статье приводятся примеры рефакторинга реальных клонов из популярного фреймворка Spring. В качестве инструментов используются Java 8, IDE IntelliJ IDEA 2017.1 и плагин Duplicate Detector 1.1.

Как известно, в Java нет беззнаковых типов. Если в Си вы могли написать unsigned int (char, long), то в Java так не получится. Однако нередко возникает необходимость в выполнении арифметических операций именно с числами без знака. На первый взгляд кажется, что беззнаковые типы в принципе-то и не особо нужны (подумаешь, MaxInt для чисел со знаком меньше в два раза, если нужны числа больше, я просто возьму long и далее BigInteger). Но основное различие на самом деле не в том, сколько различных неотрицательных чисел можно положить в signed или unsigned int, а в том, как над ними производятся арифметические операции и сравнения. Если вы работаете с бинарными протоколами или с двоичной арифметикой, где важен каждый используемый бит, нужно уметь выполнять все основные операции в беззнаковом режиме. Рассмотрим эти операции по порядку:

Преобразование byte в short (int, long)

Обычный каст (int) myByte выполнит расширение до 32 бит со знаком — это означает, что если старший бит байта был установлен в 1, то результатом будет то же самое отрицательное число, но записанное в 32-битном формате:

0xff -> 0xffffffff (-1)

Часто это не то, чего бы мы хотели. Для того, чтобы выполнить расширение до 32 бит без знака и получить 0x000000ff, в Java можно записать:

int myInt = myByte & 0xff;
short myShort = myByte & 0xff;

Сравнение без учёта знака

Для беззнакового сравнения есть лаконичная формула:

int compareUnsigned(int a, int b) {
    return Integer.compare( a ^ 0x80000000, b ^ 0x80000000 );
}

Для byte, short и long, соответственно, константы будут 0x80, 0x8000 и 0x8000000000000000L.

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


Тем не менее, есть хорошая новость: incredible machine все-таки может быть полезна. Например, для тестирования программных систем.

Деревья. Кратко напомним

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

Мы тут немного поработали ассенизаторами.

Около 66% атак первой волны пришлось на российские сети. И здесь есть огромное заблуждение: почему-то все называют механизм поиска определённого домена killswitch'ем. Так вот, возможно, нет. В случае российских сетей госкомпаний, финансов и производств — это механика обхода песочниц. Основные песочницы на входе в защитный периметр имеют множество тестов. В частности, при запросе определённых сайтов изнутри песочницы они умеют отдавать, например, 200 ОК или 404. Если приходит подобный ответ, зловред мгновенно деактивируется — и таким образом проходит динамический анализатор кода. От статического анализа он защищён несколькими свертками сжатия-шифрования. Таким образом, это не killswitch, а одна из новых механик обхода песочниц.

Об этом я тоже расскажу, но куда интереснее другой практический вопрос: какого чёрта полегло столько машин от троянца? Точнее, почему все вовремя не запатчились или не отключили SMB 1.0? Это же просто как два байта переслать, правда же?

Пришло время вновь проверить проект FreeBSD и продемонстрировать, что даже в таких серьезных и качественных проектах анализатор PVS-Studio легко находит ошибки. В этот раз я решил взглянуть на поиск ошибок с точки зрения обнаружения потенциальных уязвимостей. Анализатор PVS-Studio всегда умел выявлять дефекты, которые потенциально можно использовать для атаки. Но мы никогда не акцентировали на этом внимание и описывали ошибки как опечатки, последствия неудачного Copy-Paste и так далее, и не классифицировали их, например, согласно CWE. Сейчас очень популярно говорить и о безопасности, и об уязвимостях, поэтому попробую немного расширить ваше восприятие нашего анализатора. PVS-Studio — это не только поиск багов, но ещё и инструмент, повышающий безопасность кода.

UPD от 2017-03-04: кто-то выполнил английский перевод. Обсуждение на Hacker News.

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

Костыли в UNIX начали возникать ещё с момента появления UNIX, а это было ещё раньше появления не только Windows, но даже вроде бы Microsoft DOS (вроде бы, мне лень проверять, проверяйте сами). Если лень читать, хотя бы просмотрите все пункты, что-нибудь интересное найдёте. Это далеко не полный список, это просто те косяки, который я захотел упомянуть.