Инкапсуляция это «Упаковка» ответственности, а совмещение данных и методов это частный случай инкапсуляции в ООП. Например — можно инкапсулировать алгоритм в функцию (или в статик метод, если угодно). А сокрытие, это следствие инкапсуляции при хорошем дизайне.
У этой дыры неплохой потенциал как по высверливанию, так и по заделыванию
Если вы можете градиентом подобрать такой шум, который обманывает сетку, то вы можете нагенерировать огромное количество семплов, что бы эту сетку дообучить. С другой стороны — как вы представляете себе применение этого вектора атаки против видеокамеры?
В таком флоу, как правило кладут в бд, что бы воркеры ночью обработали. Если это большие бинарные данные, то имеет смысл хранить это в nosql бд, или скрыть за микросервисом ну или ходить по ftp или же… хранить в файлах -) Но опять таки — синхронизация, бессердечная тварь…
1) Синхронизация работы с файлами из разных процессов
2) Отсутствие каких либо стандартов по работе с файлами
3) Задержки
4) Очистка файлов после работы
5) Возможность случайно вмешаться работу между приложениями
6) Программы должны быть ТОЛЬКО на одной машине. Не масштабируемое решение.
7) Программы могут общаться только 1 на 1
8) Скорость
… продолжите список
Сразу скажу что я не астрофизик, чем снимаю с себя часть отвественности ;)
В кратце — пространство время закручивается и это влияет на гравитационное линзирование.(и на то как мы видим свет около ЧД)
Возьмем звезду. Звезда вращается (имеет угловой момент W), имеет массу M и заряд Q. Сначала сожмем ее до размера нейтронной звезды. По закону сохранения — эта звезда оставит харрактеристики
W,M,Q (если мы не будем ее особо взрывать). Более того — подобно фигуристу она ускорит вращение. Затем продолжим и сожемем в шарик для гольфа (ох уж сила воображения) и W,M,Q по прежнему не изменится.
Т.К. сингулярность — чисто математический трюк (скорее всего это место, где СТО перестает работать), то чисто математически мы можем и далее уменьшать радиус, и в конце концов устремить радиус к 0. тоесть lim r->0.
Но это никак не повлияет на {W,M,Q} так как закон сохранения никуда не девался. Подробнее тут.
Итого:
1) Гипотеза об отсутсвии волос говорит о том что чд описывается массой, моментом и зарядом
2)…
3) СТО не запрещает. Вращение влияет на окружающее пространство-время
4) Говоря о ЧД мы говорим о полной массе. Насколько я понимаю — к точке сингулярности вещество добирается за конечное время
1) Понятие массы для ЧД остается. Сингулярность будет по плотности. Точка массы M, с бесконечной плотностью. При этом радиус ГС зависит от M. (F(M))
2) Будет. ЧД отличаются только массой и закрутом.
3) Сингулярность — вращается) Она хоть и точка, но тоже человек. Хоть и с бесконечной плотностью — но все же это продукт наших мат моделей;) Может быть она размером с шарик для гольфа в конце концов (если СТО на таких плотностях работает по другому).
Спасибо за прекрасную статью. Но напршивается Янь к этому Инь.
«И работу дворника можно превратить в искусство» — говорили мне родители.
Я несколько лет работал программистом в «креативном» месте, и только после этого попал в интерпрайз (мне повезло — отличный опыт). И я попрежнему согласен с утверждением моих родителей.
Да есть места в которых нет ничего кроме беклога, скрима, агила и регламентов. Но в них есть деньги и очень понятный и стабильный способ их получения. И многие дрессируют себя на набор рефлексов «выполнил регламент, закрыл спринт, написал код по гайдлайнам — получил X тысяч баксов». Мозг отчаянно утверждает что эту зону комфорта рушить нельзя (особенно после 30-ти).
Автор говорит про гаражные времена и великого творца внутри, однако не может работать со своей зоной комфорта. Не творец он. Он только хочет им казаться.
Автор говорит про плохое качество кода вокруг, за пределами интерпрайза, но что насчет кода в этом самом интерпрайзе? KISS-код покрывающий беклог за деньги. Топорный код который сложно критиковать. Подчеркну — не «хороший код», а тот который сложно критиковать. Автор привык к одному стилю. Автор не хочет меняться. Посмотрите код парсера в Roslyn- компиляторе (Switch-case на 600 строк кода в файле на 4к строчек, Карл!). И тем ребятам сложно высказать. Или же речь идет о связках Fp-Akka-Mongo-ПотомуЧтоЯМогу?
Автор сетует на то что он «не инженер», в отличие от его бати. Конечно. Работа в интерпрайзе — это работа автомеханника, который знает все регламенты и методологии для CRUD-like сервисов. Корпоративная культура старается этот как-то разукрасить.
Но ведь есть и другой мир, где велосипеды — рутина, алгоритмы и структуры данных — образ мышления, switch на 50 кейсов — это изящное, хитрое, и более читабельное (если ты можешь смотреть глазами) решение, а ответы приходят внезапно и оказваются замковым камнем. Только рынок меньше. И в нем гораздо сложнее (если вообще возможно) стать Дартаньяном.
Нужно уметь меняться.
Не бояться стать чайником (самому это дико страшно и болезненно раз за разом)
Не бояться терять авторитет.
Не бояться дропнуться в деньгах.
Охранять своего ребенка.
Тролить своего нарцисса.
Следовать мечте и верить в себя.
И что-то да получится -)
(под автором я понимаю темную сторону образа из статьи)
Если убрать заград пошлины то все автопроизводители России загнутся. Не только из-за качества но и из-за объемов производства и отставания в технологиях. Новые производители в обозримом будущем не появятся.
Это просто Extesion методы там где они и должны быть. Не путать с множественным наследованием, так как последнее создает неочивидную запутанность через жонглирование приватными и протектед элементами скрытыми от вас. Extension методы внутри интерфейса просто позволяют вам разделить тип на минимальный базис, и навесное оборудование, избавив от бесконечных UserHelper, UserExtensions и UserTools.
HAPI напомнил известный в электроэнергетике протокол- IEC 61850/8.1
Кто сталкивался тот поймет ощущение незабываемых недель, когда два крупных вендора (или даже два отдела одного очень крупного вендора) пытались наладить связь друг с другом, в тот момент когда вендор поменьше городил все новые if-чики, что бы связаться хоть с кем-то.
Не будет. Как правильно выше сказали — «наличие возможности именовать переменные как угодно, не доставляет проблем».
Многое из того что есть и удивляет в котлине есть в C# и у нас с этим нет трудностей. Напротив — код очень выразителен и краток. Уверен вам тоже самое скажут и Swift — программисты.
Все же результат продуманный и профессиональный. Другое дело что к ТуТу не подходит и вся айдентика растеряна, но если взять только метрики — то все зашибись.
TDD != написать какие угодно тесты в проект. TDD подразумевает написание Юнит тестов (атомарных, не интеграционных) и написание их до или во время написания основного кода.
Если я правильно понимаю суть TDD и юнит тестирования в целом- то код должен был тестироваться атомарно и без зависимостей, что в общем то исключает возможность спагетти.
Ежели под «ТDD» тут понимается написание функциональных тестов перед написанием кода, то значит есть хорошая документация. Это должна быть хорошая отправная точка для декостылизации.
Ежели под «TDD» здесь понимается написание больших интеграционных и функциональных тестов после кодинга, то получается… что написание интеграционных и функциональных тестов (и только) это яд для больших проектов. Никогда не думал о таком.
Ежели суть TDD я понимаю не правильно. То я точно узнаю об этом от комментаторов -)
Есть 10 типов людей — которые не видят разницы между процедурным и ооп подходами. А также 10 типов людей которые не видят разницы между функциональным и процедурным подходами.
Инкапсуляция это «Упаковка» ответственности, а совмещение данных и методов это частный случай инкапсуляции в ООП. Например — можно инкапсулировать алгоритм в функцию (или в статик метод, если угодно). А сокрытие, это следствие инкапсуляции при хорошем дизайне.
ZanudaMode.Off()
2) Умножь на пи и прибавь неделю
3) Позови скрам-мастера
4) Декомпозируй
5) Повтори с п2 для каждой подзадачи
Если вы можете градиентом подобрать такой шум, который обманывает сетку, то вы можете нагенерировать огромное количество семплов, что бы эту сетку дообучить. С другой стороны — как вы представляете себе применение этого вектора атаки против видеокамеры?
2) Отсутствие каких либо стандартов по работе с файлами
3) Задержки
4) Очистка файлов после работы
5) Возможность случайно вмешаться работу между приложениями
6) Программы должны быть ТОЛЬКО на одной машине. Не масштабируемое решение.
7) Программы могут общаться только 1 на 1
8) Скорость
… продолжите список
В кратце — пространство время закручивается и это влияет на гравитационное линзирование.(и на то как мы видим свет около ЧД)
Возьмем звезду. Звезда вращается (имеет угловой момент W), имеет массу M и заряд Q. Сначала сожмем ее до размера нейтронной звезды. По закону сохранения — эта звезда оставит харрактеристики
W,M,Q (если мы не будем ее особо взрывать). Более того — подобно фигуристу она ускорит вращение. Затем продолжим и сожемем в шарик для гольфа (ох уж сила воображения) и W,M,Q по прежнему не изменится.
Т.К. сингулярность — чисто математический трюк (скорее всего это место, где СТО перестает работать), то чисто математически мы можем и далее уменьшать радиус, и в конце концов устремить радиус к 0. тоесть lim r->0.
Но это никак не повлияет на {W,M,Q} так как закон сохранения никуда не девался. Подробнее тут.
Как это выглядит с точки зрения наблюдателя и как к этому пришли
Итого:
1) Гипотеза об отсутсвии волос говорит о том что чд описывается массой, моментом и зарядом
2)…
3) СТО не запрещает. Вращение влияет на окружающее пространство-время
4) Говоря о ЧД мы говорим о полной массе. Насколько я понимаю — к точке сингулярности вещество добирается за конечное время
2) Будет. ЧД отличаются только массой и закрутом.
3) Сингулярность — вращается) Она хоть и точка, но тоже человек. Хоть и с бесконечной плотностью — но все же это продукт наших мат моделей;) Может быть она размером с шарик для гольфа в конце концов (если СТО на таких плотностях работает по другому).
«И работу дворника можно превратить в искусство» — говорили мне родители.
Я несколько лет работал программистом в «креативном» месте, и только после этого попал в интерпрайз (мне повезло — отличный опыт). И я попрежнему согласен с утверждением моих родителей.
Да есть места в которых нет ничего кроме беклога, скрима, агила и регламентов. Но в них есть деньги и очень понятный и стабильный способ их получения. И многие дрессируют себя на набор рефлексов «выполнил регламент, закрыл спринт, написал код по гайдлайнам — получил X тысяч баксов». Мозг отчаянно утверждает что эту зону комфорта рушить нельзя (особенно после 30-ти).
Автор говорит про гаражные времена и великого творца внутри, однако не может работать со своей зоной комфорта. Не творец он. Он только хочет им казаться.
Автор говорит про плохое качество кода вокруг, за пределами интерпрайза, но что насчет кода в этом самом интерпрайзе? KISS-код покрывающий беклог за деньги. Топорный код который сложно критиковать. Подчеркну — не «хороший код», а тот который сложно критиковать. Автор привык к одному стилю. Автор не хочет меняться. Посмотрите код парсера в Roslyn- компиляторе (Switch-case на 600 строк кода в файле на 4к строчек, Карл!). И тем ребятам сложно высказать. Или же речь идет о связках Fp-Akka-Mongo-ПотомуЧтоЯМогу?
Автор сетует на то что он «не инженер», в отличие от его бати. Конечно. Работа в интерпрайзе — это работа автомеханника, который знает все регламенты и методологии для CRUD-like сервисов. Корпоративная культура старается этот как-то разукрасить.
Но ведь есть и другой мир, где велосипеды — рутина, алгоритмы и структуры данных — образ мышления, switch на 50 кейсов — это изящное, хитрое, и более читабельное (если ты можешь смотреть глазами) решение, а ответы приходят внезапно и оказваются замковым камнем. Только рынок меньше. И в нем гораздо сложнее (если вообще возможно) стать Дартаньяном.
Нужно уметь меняться.
Не бояться стать чайником (самому это дико страшно и болезненно раз за разом)
Не бояться терять авторитет.
Не бояться дропнуться в деньгах.
Охранять своего ребенка.
Тролить своего нарцисса.
Следовать мечте и верить в себя.
И что-то да получится -)
(под автором я понимаю темную сторону образа из статьи)
Кто сталкивался тот поймет ощущение незабываемых недель, когда два крупных вендора (или даже два отдела одного очень крупного вендора) пытались наладить связь друг с другом, в тот момент когда вендор поменьше городил все новые if-чики, что бы связаться хоть с кем-то.
Многое из того что есть и удивляет в котлине есть в C# и у нас с этим нет трудностей. Напротив — код очень выразителен и краток. Уверен вам тоже самое скажут и Swift — программисты.
Если я правильно понимаю суть TDD и юнит тестирования в целом- то код должен был тестироваться атомарно и без зависимостей, что в общем то исключает возможность спагетти.
Ежели под «ТDD» тут понимается написание функциональных тестов перед написанием кода, то значит есть хорошая документация. Это должна быть хорошая отправная точка для декостылизации.
Ежели под «TDD» здесь понимается написание больших интеграционных и функциональных тестов после кодинга, то получается… что написание интеграционных и функциональных тестов (и только) это яд для больших проектов. Никогда не думал о таком.
Ежели суть TDD я понимаю не правильно. То я точно узнаю об этом от комментаторов -)