Pull to refresh
3
0
Роман @svistkovr

Пользователь

Send message

Для измерения толщины лучше использовать механический тактильный датчик. Пруток пропускается через два прорезиненных ролика на пружинке и замеряется расстояние между роликами. Аналогичный механизм работает в шариковой ручке, там вместо прутка идёт дозировка чернил. Замерять можно как через оптопару так и ёмкостным способом. Для точности в 0.13-0.05 мм под FDM принтеры этого с головой хватит. Помимо толщины с такого датчика можно получать карту шероховатости поверхности прутка.
Преимущество перед камерой в том что идёт поток единичного значения в реалтайме, в то время когда на камере надо пройтись по всей матрице пикселей несколько раз и ещё какую-то обработку по распознаванию сделать.

P.S. Также такой датчик можно напрямую подключить через простой дифференциатор к блоку управления скоростью и через обратную связь управлять скоростью движения прутка в реальном времени.

Можно заменить (y % 100) != 0 на (y % 25) != 0

(y % 400) == 0 на (y % 16) == 0

непонятно откуда вы берёте такое сокращение. они дают разный результат
например
150 % 100 = 50 возвращает true так как не равно 0
150 % 25 = 0 возвращает false так как равно 0

«А как назвать разработчика, который технически силён, кодит быстро, но при этом не делится знаниями и работает строго в одиночку?»

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

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

Если бы проблема была только в конфигурации сборки. Большую часть времени занимает сама компиляция, особенно если надо раскрыть все макросы.
Вот вам парочку советов из Gentoo сообщества:
1) создаем виртуальный диск в оперативной памяти tmpfs и компилим на нём.
2) ccache для кеширования сборки
3) distcc для распределённой компиляции

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

Зря столько критики в адрес макросов. Неопытные программисты думают что весь код это только в .c и .h файлах - но это не так.
Очень часто надо задать конфигурацию проекта и окружения сборки. Потом всё это пропихнуть в код. Вот макросы позволяют сделать нечто подобное.

где-то в скрипте сборки:
echo "#define MY_MACROS_VARIABLE "\"$(uname)\" > my_project_config.h

потом в коде:

#include "my_project_config.h"
printf("%s",MY_MACROS_VARIABLE);

В современных автосборщиках и IDE это делается из коробки потому и не видно что происходит.

9--Треугольные функции из вложенных if if if if if if

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

Как-то мне пришлось патчить древнюю библиотеку fontconfig. Так вот там помимо пачки условий еще куча goto операторов.

Objective-c живее всех живых. Работа с сырой памятью в swifte это сплошной ад. Все низкоуровневые либы и драйвера и даже ядро mac/ios на objective-c/c++.
Эта история напоминает холивар rust <-> c в linux, где тоже пытаются сишку хоронить.

Основная проблема в том что все жалуются на паскаль или си в школе или вузе. Потом "продвинутые" преподы по всяким js,python,swift и подкладывают свинью. Просто перестали изучать преобразование типов, битовые операции, арифметику с дробями и т.д.

Дано(псевдокод)
переменные a и b это допустимый пользовательский ввод
var a = 30

var b = -1.3

var d = a&b
так чему должно быть равно d и в каком языке??

можно, но с одним исключением - делить надо в 16-ричной системе.
например
в десятичной 10 * 10 = 100 => 100 / 10 = 10
в шестнадцетиричной A * A = 64 => 64 / A = A .
мы все учили в школе таблицу умножения в десятичной системе, но умножение и деление в других системах счисления надо проводить иначе.
для ручного быстрого перевода используют методы из статьи.

Эту задачу про тележку явно не инженеры придумали, а эффективные менеджеры. Там всё неправильно ибо надо с самого начала закладывать защиту от дураков и резервные системы, если у нас низкая надёжность блоков.

Но попробуем решить хоть как-то.
Суть задачи:
Отказала система тормозов. У нас на дороге 2 препятствия.
Варианты:
- Отключить разгон. Может хоть как-то уменьшит скорость.
- Если есть возможность сворачиваем в другую строну от препятствий.
- Пробуем сдать назад чтобы сбросить скорость.
- На крайний случай жертвуем водителем. Если этот дурак не проверил свою систему до поездки ему и нести отвественность. Пешеходы в этом не виноваты.

P.S. Если бы авиация развивалась подобным способом, то мы бы до сих пор ездили поездами.

message_len = FormatLogMessageForDisplay вызывается дважды в коде до malloc и после.

wmessage_buflenтам 3 присваивания :
1)int wmessage_buflen = countof(wbuf) - 1; // wmessage_buflen==511
2)wmessage_buflen = message_len; //если message_len<=0 то сюда точно не дойдёт
3)wmessage_buflen = MultiByteToWideChar

так зачем нужна проверка после MultiByteToWideChar , если по документации не может вернуть отрицательное число или 0?

в куске кода как минимум 2 потенциальные утечки

на 512 и более байт:

//...
message_buf = std::malloc
message_len = FormatLogMessageForDisplay
//...
if (message_len <= 0)
    return;

и 2048 и более байт:

//...
wmessage_buf = std::malloc
wmessage_buflen = MultiByteToWideChar
//...
if (wmessage_buflen <= 0)
    return;

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

Например, российские пользователи Steam не смогут купить новую игру — оплата не пройдет.

Вообще-то Steam принимает карты МИР.

Видимо они не хотят светиться в политсраче.

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

А откуда они знают что пользователи заклеивают?
Не поможет. Человеку с подозрением на заражение достаточно пройти рядом с вашим домом, а потом доказывайте что вы были в помещении и у вас окна закрыты.
Это не вагон а труповозка. Любому сердечнику станет плохо уже через пару часов в этом гробу. У вас там нет ни вентиляции, ни терморегуляции. Даже не называйте ту пипирку в стене — вентиляцией. Человек должен хоть как-то сидеть в вагоне или иметь возможность, ноги будут затекать.
Купите своим дизайнерам билет на лето от Краснодара до Владивостока и обратно на верхнюю полку плацкартного вагона. Пусть пару недель покатаются по стране и это будет идеальный урок как делать не стоит.

Information

Rating
7,832-nd
Location
Краснодар, Краснодарский край, Россия
Date of birth
Registered
Activity