Расса потянуло на воспоминания о том как создавалось репо Go.
https://research.swtch.com/govcs
For what it’s worth, I’ve since heard from many people about how the 1972 dates have broken various presentations and analyses they’ve done on the Go repository as compared to other projects. Oops! My apologies. (I also heard from someone who was analyzing Mercurial repos for “branchiness” and decided to use the Go repo as a large test case. Their program said it had branchiness 0 and they spent a while debugging their program before realizing that the repo really was completely linear, thanks to our “rebase and merge” policy.)
хех
https://research.swtch.com/govcs
For what it’s worth, I’ve since heard from many people about how the 1972 dates have broken various presentations and analyses they’ve done on the Go repository as compared to other projects. Oops! My apologies. (I also heard from someone who was analyzing Mercurial repos for “branchiness” and decided to use the Go repo as a large test case. Their program said it had branchiness 0 and they spent a while debugging their program before realizing that the repo really was completely linear, thanks to our “rebase and merge” policy.)
хех
Когда человек делает тестовое задание на 2к линий и на 22 файла (на Go), то у меня возникает паника: а на какое безумство готов пойти этот человек в команде?
Не, конечно же хочется написать хорошее решение, потом его сделать публичным и получить 2й прометеус, но реальность чуть другая и тестовое задание не более чем маркер - говорить дальше или нет (даже разговор потом это не 100% гарантия хорошего кандидата, кэп).
А вот душнота в тестовом - неприятная вещь. Ты вроде читаешь и пытаешься понять, как думал человек, а в итоге смотришь на его/её логгер или 3 варианта решения для стореджа. Ну приятно, но смысла мало, если бы я увидел комент "вот тут на каналах, но можно на мютексе" - я бы был более рад.
Но и 150 строк без объяснения в одном файле это другая сторона - анти-душность. Вроде и правильно написано, но непонятно, а что человек может еще? или хотя бы может о чем-то подумать.
Наверное в виде совета сказал бы такое - ревьюверы не хотят делать ревью, ну вот прям такое супервдумчивое с 2мя созвонами по 1 фции, ну как с рабочим репо, но при этом хочется видеть о чем думает и о чем может думать кандидат.
Может и не надо писать много коментов в коде, но если в README написать TODO чего не хватает или что хочется потрогать (фаззинг/jepsen/etc) то лучше сказать, мне это не раз помогало найти крутых кандидатов.
Не, конечно же хочется написать хорошее решение, потом его сделать публичным и получить 2й прометеус, но реальность чуть другая и тестовое задание не более чем маркер - говорить дальше или нет (даже разговор потом это не 100% гарантия хорошего кандидата, кэп).
А вот душнота в тестовом - неприятная вещь. Ты вроде читаешь и пытаешься понять, как думал человек, а в итоге смотришь на его/её логгер или 3 варианта решения для стореджа. Ну приятно, но смысла мало, если бы я увидел комент "вот тут на каналах, но можно на мютексе" - я бы был более рад.
Но и 150 строк без объяснения в одном файле это другая сторона - анти-душность. Вроде и правильно написано, но непонятно, а что человек может еще? или хотя бы может о чем-то подумать.
Наверное в виде совета сказал бы такое - ревьюверы не хотят делать ревью, ну вот прям такое супервдумчивое с 2мя созвонами по 1 фции, ну как с рабочим репо, но при этом хочется видеть о чем думает и о чем может думать кандидат.
Может и не надо писать много коментов в коде, но если в README написать TODO чего не хватает или что хочется потрогать (фаззинг/jepsen/etc) то лучше сказать, мне это не раз помогало найти крутых кандидатов.
Forwarded from Experimental chill
В общем, держите картинку, которую я склепал из своего опыта. Могу где-то ошибаться, но на дворе 2022 год, у нас до сих пор нет
1. Безопасного
2. Быстрого
3. С поддержкой многих регулярных выражений
4. С хорошим support и funding
5. Хорошо оттестированного
6. Мультиплатформенного
7. С контролем по ресурсам
8. И streaming модом
Движка регулярных выражений.
Я всё понял. Делаем, значит, RE3.
[1] Мой блог по hyperscan
[2] Диссертация по ReDoS
[3] Cloudflare ReDoS postmortem, StackOverflow ReDoS postmortem
[4] ReDoS in production
[5] Hyperscan paper
[6] Vectorscan issues
[7] Hyperscan correctness issues
[8] std::regex slower than python
[9] Rust regex benchmarks
[10] RE2 syntax
Ссылка на первую часть
1. Безопасного
2. Быстрого
3. С поддержкой многих регулярных выражений
4. С хорошим support и funding
5. Хорошо оттестированного
6. Мультиплатформенного
7. С контролем по ресурсам
8. И streaming модом
Движка регулярных выражений.
Я всё понял. Делаем, значит, RE3.
[1] Мой блог по hyperscan
[2] Диссертация по ReDoS
[3] Cloudflare ReDoS postmortem, StackOverflow ReDoS postmortem
[4] ReDoS in production
[5] Hyperscan paper
[6] Vectorscan issues
[7] Hyperscan correctness issues
[8] std::regex slower than python
[9] Rust regex benchmarks
[10] RE2 syntax
Ссылка на первую часть
Хашимото (тот что батя Hashicorp-а) про Zig писать начал и даже спонсорить на Гитхабе.
https://mitchellh.com/zig
Митчел конечно не Кармак, чтобы бегом рвануть и писать все на Zig, но приятно как-то, видно зацепило его и понравилось.
https://mitchellh.com/zig
Митчел конечно не Кармак, чтобы бегом рвануть и писать все на Zig, но приятно как-то, видно зацепило его и понравилось.
Mitchellh
Zig – Mitchell Hashimoto
My writings about the Zig programming language.
TLDR: БД на Macbook-ах лучше не гонять.
REKT https://twitter.com/marcan42/status/1494213855387734019
Вообще-то....странно, что такой тред только сейчас всплыл, Apple вроде давно бенчами SSD хвастался и всегда(часто?) был лидером, а вот как все просто оказалось.
Конечно есть шанс, что автор что-то напутал, но Гектор известный человек и вряд ли так тупнул, но cmd+S теперь хочется чаще нажимать.
REKT https://twitter.com/marcan42/status/1494213855387734019
Вообще-то....странно, что такой тред только сейчас всплыл, Apple вроде давно бенчами SSD хвастался и всегда(часто?) был лидером, а вот как все просто оказалось.
Конечно есть шанс, что автор что-то напутал, но Гектор известный человек и вряд ли так тупнул, но cmd+S теперь хочется чаще нажимать.
Forwarded from AppSec & Compliance
https://github.blog/2022-02-17-code-scanning-finds-vulnerabilities-using-machine-learning/
GitHub объявил о добавлении в сервис Code scanning экспериментальной системы машинного обучения для выявления распространённых типов язвимостей в коде. На этапе тестирования новая функциональность пока доступна только для репозиториев с кодом на языках JavaScript и TypeScript. Отмечается, что применение системы машинного обучения позволило заметно расширить спектр выявляемых проблем, при анализе которых система теперь не ограничивается проверкой типовых шаблонов и не привязывается к известным фреймворкам. Из выявляемых новой системой проблем упоминаются ошибки, приводящие к межсайтовому скриптингу (XSS), искажению файловых путей (например, через указание "/.."), подстановке SQL- и NoSQL-запросов.
Сервис Code scanning позволяет выявлять уязвимости на ранней стадии разработки через сканирование каждой операции "git push" на предмет потенциальных проблем. Результат прикрепляется непосредственно к pull-запросу. Ранее проверка осуществлялась с использованием движка CodeQL, анализирующего шаблоны с типовыми примерами уязвимого кода (CodeQL позволяет сформировать шаблон уязвимого кода для выявления наличия подобной уязвимости в коде других проектов). Новый движок, использующий машинное обучение, может определять ранее не известные уязвимости так как он не привязан к перебору шаблонов кода, описывающих конкретные уязвимости. Ценой подобной возможности является увеличение числа ложных срабатываний по сравнению с проверками на основе CodeQL. (https://www.opennet.ru/opennews/art.shtml?num=56719)
GitHub объявил о добавлении в сервис Code scanning экспериментальной системы машинного обучения для выявления распространённых типов язвимостей в коде. На этапе тестирования новая функциональность пока доступна только для репозиториев с кодом на языках JavaScript и TypeScript. Отмечается, что применение системы машинного обучения позволило заметно расширить спектр выявляемых проблем, при анализе которых система теперь не ограничивается проверкой типовых шаблонов и не привязывается к известным фреймворкам. Из выявляемых новой системой проблем упоминаются ошибки, приводящие к межсайтовому скриптингу (XSS), искажению файловых путей (например, через указание "/.."), подстановке SQL- и NoSQL-запросов.
Сервис Code scanning позволяет выявлять уязвимости на ранней стадии разработки через сканирование каждой операции "git push" на предмет потенциальных проблем. Результат прикрепляется непосредственно к pull-запросу. Ранее проверка осуществлялась с использованием движка CodeQL, анализирующего шаблоны с типовыми примерами уязвимого кода (CodeQL позволяет сформировать шаблон уязвимого кода для выявления наличия подобной уязвимости в коде других проектов). Новый движок, использующий машинное обучение, может определять ранее не известные уязвимости так как он не привязан к перебору шаблонов кода, описывающих конкретные уязвимости. Ценой подобной возможности является увеличение числа ложных срабатываний по сравнению с проверками на основе CodeQL. (https://www.opennet.ru/opennews/art.shtml?num=56719)
The GitHub Blog
Code scanning finds more vulnerabilities using machine learning
Today we launched new code scanning features powered by machine learning. The experimental analysis finds more of the most common types of vulnerabilities.
Про внутренности Go fuzz в 1.18 от автора (ну одного из, но который ушел в саббатикал, хех) https://jayconrod.com/posts/123/internals-of-go-s-new-fuzzing-system
Кажется похожее было и о go-fuzz от Вьюкова, может даже в репо, проверять я не буду.
Кажется похожее было и о go-fuzz от Вьюкова, может даже в репо, проверять я не буду.
jayconrod.com
Internals of Go's new fuzzing system
Go 1.18 is coming out soon. It's a huge release, but native fuzzing has a special place in my heart. Not much has been written yet on how Go's fuzzing system actually works, so I'll talk a bit about that here.
oleg_log
Про внутренности Go fuzz в 1.18 от автора (ну одного из, но который ушел в саббатикал, хех) https://jayconrod.com/posts/123/internals-of-go-s-new-fuzzing-system Кажется похожее было и о go-fuzz от Вьюкова, может даже в репо, проверять я не буду.
Ну да, точно было https://github.com/dvyukov/go-fuzz/blob/master/slides/algo.png
Мне кажется я нашел самый отвратительный го.мод, хотя я и не искал, но это прям треш.
Оно хоть и прокоменчено и понятно почему такие костыли вправлены (ну как же без них в нашей индустрии), но...втф-то?
Колосс на глиняных ногах вспоминается.
https://github.com/DataDog/datadog-agent/blob/main/go.mod
Оно хоть и прокоменчено и понятно почему такие костыли вправлены (ну как же без них в нашей индустрии), но...втф-то?
Колосс на глиняных ногах вспоминается.
https://github.com/DataDog/datadog-agent/blob/main/go.mod
GitHub
datadog-agent/go.mod at main · DataDog/datadog-agent
Main repository for Datadog Agent. Contribute to DataDog/datadog-agent development by creating an account on GitHub.
oleg_log
Про внутренности Go fuzz в 1.18 от автора (ну одного из, но который ушел в саббатикал, хех) https://jayconrod.com/posts/123/internals-of-go-s-new-fuzzing-system Кажется похожее было и о go-fuzz от Вьюкова, может даже в репо, проверять я не буду.
Короч fuzzing еще не зарелижен, а никого из авторов в команде уже нет. Сильно....
https://twitter.com/katie_hockman/status/1494701223538216965
https://twitter.com/katie_hockman/status/1494701223538216965
Статья хорошая, но ссылка на скрипт в твите еще лучше. Продублирую комент к статье: поменяв порядок колонок в табличке - получилось сэкономить 6-7% на каждой таблице (а их много, партиции, так сказать)
https://twitter.com/samokhvalov/status/1496227451319500800
Не скажу, что вам это надо везде, но если таблица исчисляется терабайтами и/или она будет терабайты в ближайшем времени, то стоит подумать про такую хитрость. Думаю до 5% дергаться нет смысла, но решать вам.
(вообще хотелось бы сказать еще много умных и практических-полезных вещей про dark bytes в других вещах, системах, доменах, но наверное потом)
https://twitter.com/samokhvalov/status/1496227451319500800
Не скажу, что вам это надо везде, но если таблица исчисляется терабайтами и/или она будет терабайты в ближайшем времени, то стоит подумать про такую хитрость. Думаю до 5% дергаться нет смысла, но решать вам.
(вообще хотелось бы сказать еще много умных и практических-полезных вещей про dark bytes в других вещах, системах, доменах, но наверное потом)
Twitter
Nikolay Samokhvalov 🇺🇦
A new post from Depesz, about disk space occupied by int4, int8, etc numbers: depesz.com/2022/02/13/how… Was going to mention my alignment padding script github.com/NikolayS/postg… – but @oleg_kovalov already did it. Thanks. "horribly amazing script" is a…
Красивая визуализаци tight vs loose coupling, мне в универе такого не хватало. Кстати понятие "граница апи" приобретает физический смысл.
Сурс https://nordicapis.com/the-difference-between-tight-coupling-and-loose-coupling/ (не читал, прост картинки посмотрел)
Сурс https://nordicapis.com/the-difference-between-tight-coupling-and-loose-coupling/ (не читал, прост картинки посмотрел)
А це вже так собі :( що ж ми, айті-нація, ось так…Дія онлайн і вже приємно, але і але.