Sign up

Profile

Posts 6

Comments 761

Bookmarks 38

  • Стоит ли жаловаться на собеседования?
    32
    +1

    И самое главное в такие компании лучше не идти работать. А если уже там, то пора смотреть по сторонам.

  • LDAP-«аутентификация» — это антипаттерн
    34
    0

    Так а кто настраивает CD? Кто ее входными данными кормит? А если данные на проде разошлись? Или просто прилетело что-то странное и роняющее все. А перешардировать прод кто будет?


    Править не на проде хорошо конечно. Но как сказал один умный человек "Когда у вас петабайты данных, то теста нет. Тест становится слишком дорогим. И что делают разработчики? Правильно! Тестируют на проде" Отсюда весь этот девопс и доступы для разработчиков.


    Логи, кодревью, аппрув от 2 человек. Это все нормальные практики для защиты прода.

  • LDAP-«аутентификация» — это антипаттерн
    34
    +1
    Какие зоны? Вы о чем вообще? К вайфаю подключился и все. Физически можно быть в любом месте офиса. К серверам подходить не надо вообще.

    Простите, если не у разработчиков то у кого доступ к проду должен быть? Кто будет править ошибки когда все сломалось? Кто новые версии разворачивать и мониторить будет? Кто ошибки которые появляются только на проде ловить будет? Эльфы?

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

    Устроится на работу в банк клерком сложно? Вы это серьезно? Естесвенно со своего, а с какого еще? К другим аккаунтам доступа быть не должно вообще.

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

    Нет, его надо просто использовать. Можно добавить 2fa для логина в места где ну совсем секретно. Или там для перевода миллиона долларов. И раздать токены кому надо. Главное чтобы эти операции были не по 100 раз на дню. Иначе пользователи автоматизируют и упростят.
  • В 26 лет Яна Харлан руководит разработкой космического двигателя. В следующем году его планируют запустить
    297
    +1
    Скепсис все держат при себе. Люди делают. Госбюджеты при этом миллиардами не тратятся.
    Пусть работают. Вдруг взлетит.
  • LDAP-«аутентификация» — это антипаттерн
    34
    +1
    У Гугла, да и у Яндекса тоже, все смотрит прямо в интернет. Я уверен что разработчики у них с полными правами на ноутах. Секретов у них больше чем у всех остальных вместе взятых. Полное досье на всех (с мизерной погрешностью) жителей Земли.
    И ничего. Все безопасно и ничего по вине Гугла не утекает. Значит дело не в правах на ноутах, а в бумерах которые думают что дело в ноуте или вообще в одежде.

    Ну так делим по такому же принципу. Доступ только к тому к чему он нужен. Операции разумно ограничены. По простому «Полная выгрузка базы не нужна среднему пользователю. Да и рейт лимитер полезно прикрутить.» Ну и так далее в зависимости от предметной области.

    Да какие мышки с джойстиками. Мы тут вроде как разработчики. На Питоне наговнокодить все можно. С любой машины. Питона нет, так я и на Баше напишу. Апи хоть какое-то есть и дальше дело техники. Соответвенно исходим из того что любой злоумышленник устроившийся на работу может сделать тоже самое.

    SSO это как раз панацея. Один пароль можно заставлять делать сложным и учить наизусть. С привязкой к компу вообще хорошо. Логин с другого компа это сразу алярм.
    А вот если пароль надо вводить по 10 раз для начала работы, то уже так не выйдет. Если пароли разные, то вообще можно сразу тушить свет. Люди извернутся, но придумают как сделать так чтобы попроще печатать было. Люди они такие.
  • LDAP-«аутентификация» — это антипаттерн
    34
    +1

    Только вот на таком работать нельзя. У обычного разработчика ноут с полными правами и всеми портами.


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

  • LDAP-«аутентификация» — это антипаттерн
    34
    0

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


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

  • LDAP-«аутентификация» — это антипаттерн
    34
    +1
    Человек должен вводить свой пароль один раз. При логине на свой компьютер.
  • LDAP-«аутентификация» — это антипаттерн
    34
    +1

    Это же код писать надо в своей приложеньки. Местами сложный.
    А по логину с паролем достаточно с so скопипастить.

  • Космодромы поближе к экватору — тропический космодром Вэньчан
    26
    +1
    Вы видео специально так положили чтобы его никто не посмотрел? Переложите на ютуб, не издевайтесь над людьми.
  • 10 признаков того, что хороший программист из вас не получится
    518
    0
    Я про личную ветку. В терминах гитхаба форк. Разработка обычно в таких ветках идет.
    Тесты гоняем до зеленых когда пулл реквест в мастер делаем.

    У тех кто терял данные на локальном диске мнение всегда одно: Комить при любом удобном случае.
  • 10 признаков того, что хороший программист из вас не получится
    518
    0
    Вы отвечаете на комент начинающийся словами «я не люблю термин 'юнит-тест'»

    Так все равно скатываемся до определений. То что тестирование as code это хорошо и правильно все в курсе и никто не спорит. Вопрос только в том что и как тестировать.

    отлично прогоняются. при каждом коммите.
    вот проект — 600 тыс строк кода. 450 тыс строк тестового кода.
    тесты идут 25 минут.

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

    Комит должен быть моментальным. Единицы минут край. Закомитить в ветку любой кусок кода который с виду работает это нормально и правильно.

    рабочий воркфлоу такой:

    Воркфлоу хороший. Только при долгих тестах его гонять по много раз не выйдет. Долго. Надо большую часть ошибок находить до тестов. Тесты скорее для самопроверки. Мол я все правильно написал.
  • 10 признаков того, что хороший программист из вас не получится
    518
    0
    Ну например знание того, что операции со строками занимают время, грубо говоря, пропорциональное длине этих строк — а для целых чисел это не так может помочь и «программисту на условном реакте».

    Это любимые всеми алгоритмы. O(n) где n длина строки. И пусть оно хоть на машине тьюринга исполняется. От железа не зависим никак.

    С одной стороны вы правы — почти ничего, кроме умения избегать алгоритма маляра Шлемиэля от разработчика в 99% случаев не требуется… с другой — не зная, хотя бы примерно, как «внутри» устроены все эти абстракции — его легко посадить где угодно.

    И это тоже обычные аглоритмы. Напиши нормальный алгоритм, и он нормально работать будет. На любой машине.

    В итоге пришли к тому что у фронтов тоже надо спрашивать на собеседованиях как развернуть список. Иначе они такого понапишут.
  • 10 признаков того, что хороший программист из вас не получится
    518
    +1
    Ваши юнит тесты все сильнее начинают напоминать интеграционные. Медленные, сложные, инфрастуктуру требуют. Их не то что при каждой сборке, а даже при каждом коммите не прогнать.

    А в интеграционных тестах уже не надо тестировать сохранение и чтение из БД User. Достаточно протестировать интерфейсы системы. Если на них все правильно, то какая разница как там что в БД сохраняется и читается? Может и БД уже нет, все порефакторили на инмемори хранение.
  • Google опубликовала результаты аукциона, который определил поисковики Android в Евросоюзе
    33
    0
    Еврокомиссия там насчет предустановленного и неудаляемого софта ничего решать не планирует? На этом еще и заработать можно. Евро телефоны с возможностью удалить все будут пользоваться спросом.
  • 10 признаков того, что хороший программист из вас не получится
    518
    0
    А разве это не плюс?

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

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

    Да да. Но ситуации разные бывают. И сроки горят, и на рефакторинг времени нет и вообще делать некому. Писать сложно и непрозрачно и прикрываться тестами иногда приходится. Главное чтобы это правилом не становилось.
  • 10 признаков того, что хороший программист из вас не получится
    518
    0
    Какое хорошее определение. Надо запомнить.

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

    У интеграционных есть один минус. Они сильно повышают требования к разработчикам. «Написать ерунду и если тест упадет перепишем» и так до всех работающих тестов уже не выйдет. Интеграционные тесты часто работают по много часов и место ошибки показывают очень примерно. Искать ими ошибки накладно по времени.
  • Применение принципов функционального программирования при проектировании ERP
    177
    0
    У вас пользователи вообще не ошибаются? Поделитесь техниками обучения пользователей?
    Логировать, конечно, надо все и вся. Кто когда и что вносит-меняет. Я бы даже алертов понаделал на странные изменения. Ну не должен пользователь менять массово и много. А с другой стороны почему бы и нет, обычная системная ошибка.

    Обычная sql база, возможно рядом не менее обычная Монга с джейсонами.
    Нагрузка смешная. Пусть даже Москва: 15кк счетчиков и 15кк событий в месяц. Работать на калькуляторе будет.

    Сложную аналитику за большие периоды считать отдельно. Как и на чем зависит от… Но в общем чего-то с большим количеством памяти и без диска хватит.
  • Применение принципов функционального программирования при проектировании ERP
    177
    0
    На словах и даже в проекте оно красиво. А потом приходят пользователи которые не понимают почему для изменения контактного телефона (просто пример незначащего поля) надо заниматься всей этой бюкратией. Почему нельзя его просто поменять? Да старый номер не нужен. В итоге незаметные для пользователя логи изменений таких вещей устраивают всех. Концы найти можно и работе не мешает.

    С иммутабельными документами все хорошо до тех пор пока не выяснится что последняя версия каждого документа собирается из пары сотен предыдущих версий. А какая-нибудь парочка особо важных и нужных документов собирается из 10к предыдущих. И когда приходит хотя бы сотня пользователей с простейшим запросом «Покажи мне актуальную версию документа» все начинает тормозить. Очень тормозить. А они еще f5 любят жать.
    Объяснить мол пусть тормозит, зато тут математически все прекрасно не выйдет.
  • Применение принципов функционального программирования при проектировании ERP
    177
    0

    А ведь пользователь прав. Все ошибаются. Если ошибка не критична для бизнес процесса, то почему ее нельзя просто исправить? Зачем вся эта бюрократия на пустом месте?


    Строить любой документ по всей истории медленно. Актуальные версии смотрят минимум в 95% случаев. И они должны работать быстро.

  • Применение принципов функционального программирования при проектировании ERP
    177
    +6
    Для одной большой таблицы с быстрыми вставками есть Кликхаус. Отлично работает в таком сценарии.

    Не надо Оракл (да и sql базы вообще) грузить на запись. Они для чтения. В sql кладем все что условно постоянно. В том же биллинге всех юзеров со всеми миллионами их свойств и связей кладем в sql и обвешиваем со всех сторон индексами. А транзакции пишем в Кликхаус.

    Не нужны вам паралельность и мапредьюс. Они не для этого. Они для данных не влазящих на один компьютер. И если там данных на грани влезания, то лучше уместить. Так проще и быстрее в среднем будет. Ключевое слово — Петабайт.
  • Применение принципов функционального программирования при проектировании ERP
    177
    +1
    Тем что диск это дорого. Его медленно читать и еще медленее писать. Если у нас МНОГО данных и соотвенно hdd еще и random read очень дорогим становится.
    С памятью никакого сравнения. Память, с учетом кеша проца, линейно читается просто замечательно.

    Так в чем проблема? Проверить идею легко же. Основные сценарии чтения: поиск, group by с простенькими аггрегатами, join, order by. И пейджинг какой-нибуд сверху. Можно просто взять и написать. Ноута хватит. Нагенерить гигов 300 данных вообще не проблема, так чтобы в память точно не влазило.
  • Применение принципов функционального программирования при проектировании ERP
    177
    +9
    Мапредьюсы и подобное нужно когда у нас петабайт данных.

    10 миллионов в месяц это даже смешно. Оно должно считаться на чем угодно без проблем. Данные даже в память влезут. Проверяйте свои алгоритмы рассчета. Там явно какие-то проблемы с ними.
  • Применение принципов функционального программирования при проектировании ERP
    177
    +6
    Делать фулл скан всего и вся для любой простейшей аналитики такое себе решение…
    Да что там аналитика, простейший поиск не по ключу это фулл скан всего.
    Про join я даже не вспоминаю. Там пачка фуллсканов вылезет. Ну или надо гиганские кеши в памяти держать.
    Система умрет при любой минимальной нагрузке.

    На что только не идут люди лишь бы нормальную sql БД не проектировать.

    И в конце-концов есть Монга. Если уж очень хранилище разных документов хочется. Но метаданные справочники и прочее подобное все равно в sql лучше.

    PS: Все, или почти все sql бд поддерживают mater-slave из коробки и переживают выпадение мастера. При падении мастера база ненадолго в ридонли падает. А потом сама поднимается на запись и работает дальше.
  • n-Queens Completion Problem — линейный алгоритм решения
    59
    +1
    А когда можно будет выложить исходники в паблик? Матлаб это сильно специфично. А так люди перепишут на плюсы и погоняют на множестве вариантов. Может и нелинейные варианты найдутся.
  • n-Queens Completion Problem — линейный алгоритм решения
    59
    +1
    Перебором каждый может. Классика бектрейсинга же.
  • 1С СППР и оценка сроков и стоимости проектов методом COCOMO II
    22
    0
    Звучит как добавить фичу в продакшен. Ну или множество связанных фич.
    Это давно решено. Релизим под флагом, включаем для тестировщиков, потом для выбранных клиентов, потом для 1%, потом для всех.

    Никаких разработок на год, с фиксированием алгоритмов (до сих пор не понимаю как в таком случае баги править). Все декомпозируем и релизим минимальными кусочками. Раз в две недели, с откатом по кнопке если что-то пошло не так. Заодно шанс разломать все без обратной совместимости понижается.
  • Arc — система контроля версий для монорепозитория. Доклад Яндекса
    63
    +1
    Фиксирование версий библиотек вроде давно придумали. В монорепозитории оно должно работать точно так же.

    Тут правда другая опасность есть. Застрять на версии 200х года и когда таки придется обновиться словить все проблемы совместимости за 15 лет разом. Но при должном отслеживании и регулярном обновлении все должно работать без проблем.
  • 1С СППР и оценка сроков и стоимости проектов методом COCOMO II
    22
    0
    Канва нет. Канва — хотим заработать денег.
    А вот все остальное меняется только так. Жизнь сейчас такая.

    Средний цикл разрабтк чего-то нового примерно такой (исследовальские проекты не трогаем, берем что-то типовое):
    1. Есть клевая идея, ресурсы на разработку выделены
    2. До полугода делается нулевая версия. Альфа какая-нибудь. Быстрее — лучше
    3. На живых пользователях проверяются что идея действительно клевая и может принести деньги
    4. До полугода эта альфа переделывается в нормальную версию. Быстрее опять же лучше. По итогам проверки на живых пользователях изменения нужны будут всегда
    5. Переходим на 2 недельный релизный цикл. Пилим фичи, правим баги


    И в какое месте вот это вот фиксирование алгоритмов вставить? И докуда оно доживет? Полгода это я взял с запасом, когда что-то действительно большое делается. Желательно на пользователях проверить пораньше.
  • 1С СППР и оценка сроков и стоимости проектов методом COCOMO II
    22
    +1
    Ау. Релизный цикл 2 недели.
    Вся эта фиксация алгоритмов уже давно на помойке истории. Никому не нужны зафиксированные на год бизнес-процессы и алгоритмы. Через год уже все 3 раза поменяется.
  • Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH
    163
    0
    Ключ через агента не утекает никак. Хотя авторизоваться можно.

    Тот кто ставит * для форварда в конфиге сам виноват. Насколько я помню в дефолтном конфиге даже коммент соответвующий есть.
  • Идея децентрализованной социальной сети следующего поколения
    190
    +1
    Фейсбук полностью закрывает потребность «Почитать ленту из тех на кого подписан». А ваша учетка Фейсбука чего-то стоит? Я понимаю там бизнесы у которых все в Фейсбуке переживают, а вам то что? Я вот за свою не переживаю. Да и банить не за что, она как раз ридонли. Почитать.

    Нельзя. Посмотрите хотя бы на Яндекс Дзен. Рекомендательная система, с неплохим антифродом. Попробуйте там почитать кликбейт недельку, а потом выбраться из пузыря. Это нетривиальная задача.
    И это модерируемая система сделанная неглупыми людьми. В опенсорс немодерируемой системе все будет гораздо хуже.
  • Идея децентрализованной социальной сети следующего поколения
    190
    0
    Так подпишитесь в Фейсбуке на интересных вам персон. И все. Вопрос решен.
    Останется проблема со слишком умной лентой Фейсбука, но это мелочи.

    yet another соцсеть с просмотром постов только тех на кого подписан не нужна. А все что больше захватят фродеры. Быстро и полностью. Будет смесь из рекламы и кликбейта. С великолепными рейтингами.
    И рядышком для красоты тороговля наркотой будет. Они тоже любят площадки с легким доступом к покупателям. Антифрода нет, все можно.
  • Идея децентрализованной социальной сети следующего поколения
    190
    +3
    Так у вас получается очень жесткий информационный пузырь. Выйти из него шансов нет, там боты. И зачем такое нужно? Проще на этих же авторов подписаться на текущих площадках.

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

    Антифрод это сложно. Сделать работающий опенсорс антифрод еще никто не смог. Если эту задачу решите, остальное все уже не нужно. Закрытые антифроды зло, но сейчас без них никак.
  • Идея децентрализованной социальной сети следующего поколения
    190
    +1
    Сделать примерно миллион ботов репостящих и даже немного рерайтящих чужие посты элементарно. Что дальше делать будете? После ручного бана еще миллион сделаю таких же. Это почти бесплатно.

    Базовый ретинг они друг другу налайкают. Немного лайков от живых людей докупить и вообще красота. Я думаю не дороже цента за лайк будет. Полный контроль над контентом. Антифрод в исходниках обойти вообще не проблема.
  • Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH
    163
    0
    надо подобрать логин юзера

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

    пароль su

    И эта часть не работает в реальной жизни. sudo по жизни без пароля для всех у кого права на него есть. Просто из соображений удобста. Люди не любят постоянно вводить сложные пароли, а от простых толка нет.
  • Как автопилот въехал в нашу жизнь, а мы и не заметили
    57
    0
    На них пошлины в другую сторону. Их хотя бы понять можно. Мол локализуйте производство и не будет пошлин. Логика есть.

    А вот этот барьер даже объяснить как-то логично нельзя. Выносите производство из страны не будет пошлин? Бред какой-то.
  • Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH
    163
    +3
    Бежать надо от такого Энтерпрайза. Они данные потеряют и тебя виновным сделают.

    Есть же типовой сценарий: Вот тебе ноут. Диск на нем шифрован. Ключ с ноута не не выносить. Ноут бери с собой. Потерял/украли срочно пиши/звони вот сюда в любое время.
  • Как автопилот въехал в нашу жизнь, а мы и не заметили
    57
    +1
    Все как обычно. Своим сертификация за 214к, а иностранцев ввози и катайся.
    214к конечно немного, но сама идея ущемления своих производителей ужастна.
  • Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH
    163
    +2

    Ноуты с tpm это удобно. Нативное прозрачное шифрование диска из коробки.


    Телефоны аналогично. Любой нормальный телефон воровать бесполезно.

Info

  • Rating 1,291–st
  • Activity 1/24/20, 12:50 AM
  • Registered July 22, 2008

Contribution to hubs

Your account

Sections

Info

Services

If you find a mistake in the post please select it and press Ctrl+Enter to send a report to the author.
© 2006 – 2020 «TM»
Language settings
About
Support
Mobile version