Большая часть из уязвимых репозитариев это «hello world” проекты?
Это действительно но страшная угроза….
Давно уже писали что ставить код из он Лайн репозитарев так себе идея. Для вас форе придумали, формацией и ставьте из «своих» репозитариев. А то в один прекрасный момент автор новую фичу выкатит которая с вами не совместима и привет.
Ага, написали на python2 а тут выкатили версию 3 у которой с обратной совместимостью проблемы. Что делать будем? А тут 70 лет проверенного кода и обратной совместимости.
Кстати не факт что питон на суперкомпьютеры понтировали на которых модели погоды гоняют. ..
Можно почитать, как маркетинговый отдел распишет про замечательную работу, но по факту все равно отстой. Телефоны в 3 раза шире стали а новые кнопки так и не могут добавить. В частности кнопки управления курсором без которых вообще треш текст редактировать.
Хорошо что на 10 итерации дошло что надо контекстное меню прикрутить ….
Статья порадовала. Особенно про не использование стандартного календаря. Из-за таких советов, постоянно хочется руки оторвать специалистам, которые на каждом сайте придумывают свой уникальный способ ввода даты.
Есть SQLite который протестирован так как корпорациям и не снилось, есть Tex, который тоже Кнутом написан а не корпорацией. Там с качеством все в порядке. Просто когда пишут специалисты а не аникейщики все получается :)
„На данный момент на маленькое событие обновления одного счётчика мы перезаписали всю колонку счётчиков, которая может иметь размер порядка десяти килобайт. Хотелось бы отправлять в БД только само произведённое изменение.
На помощь приходят бинарные дельта-кодеки, в частности, xdelta. Он позволяет вычислить diff между любой парой бинарных строк, а затем наложить его на оригинальную строку и получить новое значение. Это как git diff и git apply, только не с текстовыми файлами в репозитории, а с любыми бинарными строками.“
Если я правильно понял то логика следующая:
RDBMS это не модно и не молодёжно, поэтому все сделаем на key/value storage.
нам надо сэкономить данные на чтение/запись - давайте часть записи хранить в отдельном поле
А как будем обновлять? Посчитаем xdelta…
было: пишем объект по ключу
Стало: читаем по ключу/ вычисляем дельту, пишем дельту.
Вместо одной операции на запись как писали выше в нормальную колонку БД где одно целое число надо заменить на другое и не надо ничего считать- нагородили огород с чтением/записью расчетом дельты.
При этом предполагаем что пока мы читаем/считаем дельту никто это поле не обновит. И если надо поменять счётчик a и счётчик b одновременно, то просто создаём себе проблему на ровном месте, которую успешно преодолеваем…
Обработчики обновляли один и тот же баннер, но у этого баннера один и тот же номер шарда, а значит, оба обработчика не могли пройти мимо обновления одного и того же значения оффсета в таблице. Но оффсеты мы обновляем исключительно транзакционно, при этом коммитим только после проверки открывшейся транзакции на ожидаемое значение. Этот механизм гарантирует, что хотя бы у одного обработчика либо упадёт проверка того, что оффсет ожидаемый, либо упадёт коммит транзакции с ошибкой конфликта записи. А когда у обработчика происходит ошибка, он полностью перезапускается, при этом сбрасывает весь свой кэш стейтов.
Кто нибудь понял о чем это, или все по диагонали читали?
Не городите огород, посмотрите как Амазон делает. Даже если у них что-то криво, то народ к этому привык и воспринимает как должное. (По крайней мере западный)
Про плагин к фотошопу тоже порадовало, вот такие специалисты нафотошорят, а вы как хотите так и трахайтесь с CSS потом, проблемы индейцев шерифа не волнуют.
За слово «дизайн» /«дизайнер» пора уже по рукам клавиатурой бить :)
Дизайнер это кто вам эскиз обстановки квартиры нарисует.
Все остальное, особенно что с разработкой связано, Web и т.д. Давно пора в «промышленный дизайн» переименовать.
Одно слово добавили и какой результат….
Промышленный дизайн это про технологичность и юзабилити а не про то какой радиус мне запилить. Теоретически можно любой, а практически берём ваш стандартный Фреймворк и радиус по умолчанию который там задан.
Если рисуете дизайн сайта, то потрудитесь посмотреть на каком фреймворка его разрабатывать будут и используйте дефолтные компоненты/ цвета.
Потом поиграйтесь с цветами если клиенту цвета по умолчанию не нравятся.
И расположение и название элементов посмотрите на самых популярных сайтах.
А вас же в машине нет кнопки «завести сейчас» и «завести завтра»?
И медли у вас во всех машинах одинаково расположены: сцепление слева, торов справа.
Глядишь и пользователей на сайте будет больше, поскольку им не придётся 2 часа думать куда нажать и где что расположено.
Очередная статья про открытие Америки через форточку. Давно известно что при смене работы можно до 20% получить повышение зарплаты. Работая на одном месте вы максимум проучите 5% в год. Соответственно лайк-хак. Меняем работу раз в три года. :)
Думаю не прокатит. Все прекрасно понимают, что затраченные усилия уже списаны и ничего не стоят.
Предложение убита 100 часов на рефакторинг обещая что потом будет лучше не работает.
Все прекрасно понимают что когда девелоперы говорят 100 часов это займёт от 200 до 400.
Дальше вы обещаете что новые фичу можно будет выкатывать за 25 часов вместо 150.
Руководитель вносит поправочные коэффициенты: новые фичи будут занимать от 50 до 75 часов поскольку программеры всегда оптимистичны.
Если мы сейчас сделали фичу за 100 часов, то скорее всего следующую вы сделаете за те же 100 часов а не 150, поскольку скорее всего ваша оценка будущей сложности завышена.
соответственно вы предлагаете убить 200-300 часов что в в будущем делать то же самое за тоже Самое время. При этом никто не знает нужна ли нам будет похожая фича в будущем или придётся все перелопачивать под новые требования.
Опять девелоперов плачут, какие плохие менеджеры - ничего не понимают, и нормальный код писать не дают ….
Технический долг ничего не стоит. За его исправление нельзя выписать счёт и отправить клиенту. Соответственно с точки зрения менеджмента - нет проблем.
Если клиент хочет фичу завтра и готов платить, то с точки зрения менеджмента надо выкатить ее в прод, и как можно скорее выставить счёт.
Бизнес это про зарабатывание денег а не про прекрасную архитектуру и отсутствие технического долга.
Вы свой бек-лог возьмите и потрите в начале года. 100% гарантии ни кто не заметит «потери бойца».
Если проблема есть- ее опять зарепортят, если не зарепортят -это не баг, это фича :)
P.S. Сам девелопер, но понимаю мотивацию менеджмента :)
Вот только настроить права нормально ещё тот квест. Да и половина программ работать перестаёт если не под админом установлена.
Автору рассказали про модель работы с git без gitlab/GitHub.
Есть ещё лайфхак.
Можно сгенерировать патч файл и послать коллеге по email/или что там у вас
Коллега может его накатить и все будет работать.
Welcome to Linux Kernel work flow :)
Большая часть из уязвимых репозитариев это «hello world” проекты?
Это действительно но страшная угроза….
Давно уже писали что ставить код из он Лайн репозитарев так себе идея. Для вас форе придумали, формацией и ставьте из «своих» репозитариев. А то в один прекрасный момент автор новую фичу выкатит которая с вами не совместима и привет.
Ага, написали на python2 а тут выкатили версию 3 у которой с обратной совместимостью проблемы. Что делать будем? А тут 70 лет проверенного кода и обратной совместимости.
Кстати не факт что питон на суперкомпьютеры понтировали на которых модели погоды гоняют. ..
Можно почитать, как маркетинговый отдел распишет про замечательную работу, но по факту все равно отстой. Телефоны в 3 раза шире стали а новые кнопки так и не могут добавить. В частности кнопки управления курсором без которых вообще треш текст редактировать.
Хорошо что на 10 итерации дошло что надо контекстное меню прикрутить ….
Читать проще чем ребусы из иконок разгадывать.
Стандартные контролы хороши тем что они стандартные.
Поэтому надо использовать то что есть а не изобретать велосипед.
Вообще-то можно просто написать Favorite.
Тупо, просто, всем понятно.
Статья порадовала. Особенно про не использование стандартного календаря. Из-за таких советов, постоянно хочется руки оторвать специалистам, которые на каждом сайте придумывают свой уникальный способ ввода даты.
Есть SQLite который протестирован так как корпорациям и не снилось, есть Tex, который тоже Кнутом написан а не корпорацией. Там с качеством все в порядке. Просто когда пишут специалисты а не аникейщики все получается :)
„На данный момент на маленькое событие обновления одного счётчика мы перезаписали всю колонку счётчиков, которая может иметь размер порядка десяти килобайт. Хотелось бы отправлять в БД только само произведённое изменение.
На помощь приходят бинарные дельта-кодеки, в частности, xdelta. Он позволяет вычислить diff между любой парой бинарных строк, а затем наложить его на оригинальную строку и получить новое значение. Это как git diff и git apply, только не с текстовыми файлами в репозитории, а с любыми бинарными строками.“
Если я правильно понял то логика следующая:
RDBMS это не модно и не молодёжно, поэтому все сделаем на key/value storage.
нам надо сэкономить данные на чтение/запись - давайте часть записи хранить в отдельном поле
А как будем обновлять? Посчитаем xdelta…
было: пишем объект по ключу
Стало: читаем по ключу/ вычисляем дельту, пишем дельту.
Вместо одной операции на запись как писали выше в нормальную колонку БД где одно целое число надо заменить на другое и не надо ничего считать- нагородили огород с чтением/записью расчетом дельты.
При этом предполагаем что пока мы читаем/считаем дельту никто это поле не обновит. И если надо поменять счётчик a и счётчик b одновременно, то просто создаём себе проблему на ровном месте, которую успешно преодолеваем…
Кто нибудь понял о чем это, или все по диагонали читали?
У швейцарской Threna есть Self Hosted решение.
У вас тема шифрования не раскрыта. Как безопасность данных обеспечиваетесь?
Тут с вами не все математики согласятся. Если не ошибаюсь то Марков отстаивал идею что 0! =0
Если уж вы про альтернативные системы то про это должны были бы знать :)
Особенно порадовала кнопка «купить завтра»
Да и «купить сейчас» тоже шедевр.
Не городите огород, посмотрите как Амазон делает. Даже если у них что-то криво, то народ к этому привык и воспринимает как должное. (По крайней мере западный)
Про плагин к фотошопу тоже порадовало, вот такие специалисты нафотошорят, а вы как хотите так и трахайтесь с CSS потом, проблемы индейцев шерифа не волнуют.
За слово «дизайн» /«дизайнер» пора уже по рукам клавиатурой бить :)
Дизайнер это кто вам эскиз обстановки квартиры нарисует.
Все остальное, особенно что с разработкой связано, Web и т.д. Давно пора в «промышленный дизайн» переименовать.
Одно слово добавили и какой результат….
Промышленный дизайн это про технологичность и юзабилити а не про то какой радиус мне запилить. Теоретически можно любой, а практически берём ваш стандартный Фреймворк и радиус по умолчанию который там задан.
Если рисуете дизайн сайта, то потрудитесь посмотреть на каком фреймворка его разрабатывать будут и используйте дефолтные компоненты/ цвета.
Потом поиграйтесь с цветами если клиенту цвета по умолчанию не нравятся.
И расположение и название элементов посмотрите на самых популярных сайтах.
А вас же в машине нет кнопки «завести сейчас» и «завести завтра»?
И медли у вас во всех машинах одинаково расположены: сцепление слева, торов справа.
Глядишь и пользователей на сайте будет больше, поскольку им не придётся 2 часа думать куда нажать и где что расположено.
«Rust предлагает хорошие решения к задачам многопоточности. В Rust нет места таким распространенным проблемам, как гонки данных…»
Ну нельзя же так над родным языком издеваться. Сначала подумал что это chat GPT нагенерил, он у него вроде поскладнее выходит.
Нет проблемы гонки данных, так как данные не гоняются.
Если пишите в официальном блоге, так хоть литературу посмотрите не предмет устоявшейся терминологии.
Вообще-то это во многих европейских странах, включая РФ незаконно. Ваша зарплата не может относиться к коммерческой тайне.
Так что можно разглашать и предложить работодателю выкинуть эту бумажку
Если вы новый офер получили, то зачем оставаться?
Какую выгоду получит работодатель подняв вам зарплату до уровня другой компании?
Если вы не уходите получив предложение, а пытаетесь торговаться значит есть факторы которые делают новую работу менее привлекательной чем текущая.
Насколько менее работодатель не может выяснить, поэтому с его точки зрения нет смысла повышать вам зарплату.
Если он создаст прецедент то к нему каждую неделю будут бегать с озёрами и просит. Повысить зарплату.
поэтому дня нег правильный ответ: всего хорошего и удачи на новом месте.
Очередная статья про открытие Америки через форточку. Давно известно что при смене работы можно до 20% получить повышение зарплаты. Работая на одном месте вы максимум проучите 5% в год. Соответственно лайк-хак. Меняем работу раз в три года. :)
Erlang вам в помощь. Попробуйте что нибудь расшарить. Он точно многопоточный и все построено на передаче сообщений. Так что не аргумент :)
Думаю не прокатит. Все прекрасно понимают, что затраченные усилия уже списаны и ничего не стоят.
Предложение убита 100 часов на рефакторинг обещая что потом будет лучше не работает.
Все прекрасно понимают что когда девелоперы говорят 100 часов это займёт от 200 до 400.
Дальше вы обещаете что новые фичу можно будет выкатывать за 25 часов вместо 150.
Руководитель вносит поправочные коэффициенты: новые фичи будут занимать от 50 до 75 часов поскольку программеры всегда оптимистичны.
Если мы сейчас сделали фичу за 100 часов, то скорее всего следующую вы сделаете за те же 100 часов а не 150, поскольку скорее всего ваша оценка будущей сложности завышена.
соответственно вы предлагаете убить 200-300 часов что в в будущем делать то же самое за тоже Самое время. При этом никто не знает нужна ли нам будет похожая фича в будущем или придётся все перелопачивать под новые требования.
Так что, предложение не принимается. :)
Опять девелоперов плачут, какие плохие менеджеры - ничего не понимают, и нормальный код писать не дают ….
Технический долг ничего не стоит. За его исправление нельзя выписать счёт и отправить клиенту. Соответственно с точки зрения менеджмента - нет проблем.
Если клиент хочет фичу завтра и готов платить, то с точки зрения менеджмента надо выкатить ее в прод, и как можно скорее выставить счёт.
Бизнес это про зарабатывание денег а не про прекрасную архитектуру и отсутствие технического долга.
Вы свой бек-лог возьмите и потрите в начале года. 100% гарантии ни кто не заметит «потери бойца».
Если проблема есть- ее опять зарепортят, если не зарепортят -это не баг, это фича :)
P.S. Сам девелопер, но понимаю мотивацию менеджмента :)