Эх… Когда-то очень давно, лет примерно 20 назад, на первой работе делали НИОКР проект по построению устройства для поиска кабеля под водой и определения глубины глубины его залегания под грунтом. Одновременно имеется ввиду. Помню сделали хитрую антенну, круглую, с кучец индукционных датчиков и контроллером, подключили ее по RS485 к ноуту… Я как раз писал прогу на Delphi еще что бы снимать данные и строить графики.
Предполагалось, что на тросе будут спускать эту антенну с катера и двигаясь в «створе» по береговым меткам в реальном времени определять место залегания и глубину залегания под грунтом. И все это предполагалось делать только при помощи пассивных электромагниных датчиков.
Даже ездили на Волгу пару раз на полевые испытания. Выяснилось, что есть две большие проблемы :)
Во первых это калибровка системы. Если в одном месте таская по двору антену еще удавалось как-то откалиброваться что бы определить расстояние до кабеля плюс минус 10см, то перейдя на новое место в 20 метрах все ползло и точность исчезала совсем. :(
Во вторых оказалось что когда антенна оказывается под водой, то ее тащит и крутит в произвольных направлениях и понять че-там вообще происходит просто не реально. А если еще и катер движется, то она вообще теряет вертикальную ориентацию полностю и про детектирование чего-либо можно просто забыть. Кстати, скорость движения или течения для этого вообще не должна быть хоть сколько нибудь большой. Даже в затонах оказывается вода движется :)
Вобщем, было интересно. Насколько понмю, тогда проект приостановили, а потом я ушел. Интересно даже че с ним стало.
Надеялся тут увидеть что-то похоже и описание технических проблем и их решений, а оказалась одна реклама и «тривиальный случай» :(
ПС Интересно в наше время че-нить придумали на эту тему?
Я вот тоже хотел спросить, а почему угол кастера не сделали? Раз при ударах такая нагрузка большая? А если еще и подпружинить при этом, будет почти как у взрослых :)
"Теперь вы можете указать в подпроекте implementation("org.apache.commons:commons-lang3:3.5"), если не ни один тип или метод из commons-lang не станет частью публичного API. "
Плюс, по моему, проблемы с несколькими разными типами посетителей. Будут либо "ифы" в методе print для каждого элемента, либо разные методы print, разделение которых тоже будет требовать какого-то "ифа".
Я не минусил. Не знаю, вранье это или нет. Не считаю США раем на земле. Но и Россию адом так же не считаю. Везде свои проблемы и способы их решения.
Но, например, за 7 лет езды в окресностях Вашингтона меня ни разу не "непропустили". Стоит включить поворотник, пропускали всегда (ну если успевали увидеть), независимо от марок, от ржавой тойоты до майбаха.
Были пару раз проблемы с паролями и пинами карточек, первый же попавшийся "консультант" в банке решал проблему в течение 20 минут. Да они особо не растекаются и следуют скриптам, но при этом если это в их компетенции они все сделают, или отведут к тому кто сделает. Однажды я забыл вовремя закрыть кредитку и закрыл с просрочкой в один или два дня, не помню уже. Получил штраф. Написал в чат поддержки, мол так и так, забыл, но уже все оплатил, можно штраф снять? Сняли.
Я это все к тому, что может то, что вы написали и не вранье, но и так категорично постулировать подобное тоже не стоит.
А разве не надо для массивов тоже использовать дженерики в этом случае? А то получается что в конечном итоге, получив из массива объект, нужно будет кастить его тип?
А чего их искать? Они же и так ищутся, когда файл собирается. Или для доступа к данным поиск как-то магически осуществляется?
Идентификаторы отличаются от доменного имени с именем файла тем, что регистраций доменных имен занимаются компании, и доменные имена можно заблокировать, убрать из DNS, разделегировать или передать кому-либо.
Т.е. набор символов, или даже не так. Набор байт, который представляет собой доменное имя регистрирует компания (звучит зловеще, давайте называть ее Вейланд Ютани), и поэтому этот набор плохо. А набор байт, который представляет собой нейкий "идентификатор" появляется от святого духа и сам мнеджет себя от дубликатов и прочих проблем. А главное, никаких компаний... Ну ок.
Если закончатся идентфикаторы, думаю, что-нибудь новое изобретут.
Грандиозно, ничего не скажешь. Для начала не мешало бы с покрытием Земли закончить. Хотя, тут может Старлинк через какое-то количество лет раздуплится...
Т.е. в некую систему собираются запихивать данные с кучи планет (ну дизайн системы я так понимаю на это рассчитан) без возможности удаления... Хм... А хранилище не лопнет?
А чем "идентификатор" принципиально отличается от связки доменного имени и имени файла? Я так понимаю тут ноги из линкуса растут с его фаловыми нодами... Ну так они там регулярно заканчиваются.
Что значит не на какой-то конкретный узел? Т.е. что бы собрать файл поедино надо какой-то нетривиальный квест пройти? Или все-таки известно где и какая его часть лежит? Тогда в чем проблема удалить? Ну кроме административных препон, которые можно обойти или взломать. Это я к "принципиальной невозможности".
Отлично. Т.е. мы туда не только все подряд будем со всех планет тянуть, у нас еще и 100500 копий всего будет...
Так просто на этот вопрос не ответить. Много очень зависит от места жительства семейного положения и т.п.
Например, для семьи с одним ребенком и с одним работающим за 100К в MD налоги будут около 20%.
Это то, что вычитается с ЗП. Если есть дом, то отдельно надо будет платить за дом.
Кроме того, есть всякие платежи, которые не являются налогом, например, медицинская страховка. Взносы в "пенсионный" фонд (ну фонда нет, но но специальные счета хорошо бы иметь), стоматологическая страховка, медицинские накопительные счета...
Много чего есть. Часть из этого берется до налогов и у каждого свои суммы получаются. Отчасти от того, что есть много вариантов и опций, отчасти от того, что ты можешь сам выбирать суммы платежей в некоторых случаях, например, на пенсионный счет.
Поэтому всегда говорят о ЗП до налогов.
В среднем, на упомянутую семью, с более-менее нормальной страховкой и не фанатичными платежами на пенсию и медицину (имеется ввиду не плата за лечение, а отчисления на накопительные счета) будет выходить около 30%
"Нет интернета, попробуйте позже"? Допустим случай, когда мы хотим гарантировать выполнение сетевого запроса пользователя, а не заставлять его искать интернет и снова повторять не удавшиеся запросы
Я аж прям колдунства какого-то ожидал :)
Ан нет. Согласен с предыдущем комментарием. И гарантий нет и несколько неудобно может получится, если в неопределенный момент в будущем неконтролируемые запросы вдруг полезут куда-то...
Предполагалось, что на тросе будут спускать эту антенну с катера и двигаясь в «створе» по береговым меткам в реальном времени определять место залегания и глубину залегания под грунтом. И все это предполагалось делать только при помощи пассивных электромагниных датчиков.
Даже ездили на Волгу пару раз на полевые испытания. Выяснилось, что есть две большие проблемы :)
Во первых это калибровка системы. Если в одном месте таская по двору антену еще удавалось как-то откалиброваться что бы определить расстояние до кабеля плюс минус 10см, то перейдя на новое место в 20 метрах все ползло и точность исчезала совсем. :(
Во вторых оказалось что когда антенна оказывается под водой, то ее тащит и крутит в произвольных направлениях и понять че-там вообще происходит просто не реально. А если еще и катер движется, то она вообще теряет вертикальную ориентацию полностю и про детектирование чего-либо можно просто забыть. Кстати, скорость движения или течения для этого вообще не должна быть хоть сколько нибудь большой. Даже в затонах оказывается вода движется :)
Вобщем, было интересно. Насколько понмю, тогда проект приостановили, а потом я ушел. Интересно даже че с ним стало.
Надеялся тут увидеть что-то похоже и описание технических проблем и их решений, а оказалась одна реклама и «тривиальный случай» :(
ПС Интересно в наше время че-нить придумали на эту тему?
Народ педали то регулярно путает, а тут про синхроность нажатиз надо помнить, да еще и когда тебя несёт куда нибудь
Отличная статья.
А вот тут нет опечатки?
"Теперь вы можете указать в подпроекте
implementation("org.apache.commons:commons-lang3:3.5"), если не ни один тип или метод изcommons-langне станет частью публичного API. "У товарища Шекли более фундаментально получилось :)
https://www.rulit.me/books/vernyj-vopros-read-102608-1.html
Плюсик конечно, но вот с т.з. дилетанта в разделах "Начнем с 2D" и "Переходим в 3D", катастрофически не хватает подробностей и картинок!
Плюс, по моему, проблемы с несколькими разными типами посетителей. Будут либо "ифы" в методе print для каждого элемента, либо разные методы print, разделение которых тоже будет требовать какого-то "ифа".
Я не минусил. Не знаю, вранье это или нет. Не считаю США раем на земле. Но и Россию адом так же не считаю. Везде свои проблемы и способы их решения.
Но, например, за 7 лет езды в окресностях Вашингтона меня ни разу не "непропустили". Стоит включить поворотник, пропускали всегда (ну если успевали увидеть), независимо от марок, от ржавой тойоты до майбаха.
Были пару раз проблемы с паролями и пинами карточек, первый же попавшийся "консультант" в банке решал проблему в течение 20 минут. Да они особо не растекаются и следуют скриптам, но при этом если это в их компетенции они все сделают, или отведут к тому кто сделает. Однажды я забыл вовремя закрыть кредитку и закрыл с просрочкой в один или два дня, не помню уже. Получил штраф. Написал в чат поддержки, мол так и так, забыл, но уже все оплатил, можно штраф снять? Сняли.
Я это все к тому, что может то, что вы написали и не вранье, но и так категорично постулировать подобное тоже не стоит.
Че то мне лень вникать, но почему объекты из массива по строковому ключу извлекаются?
А то, что в массиве могут содержаться объекты разных типов это по моему вообще нарушение сути понятия "массив".
Зачем вообще тогда тут городить огород с дженериками если конечному пользователю все равно кастить? Да еще и так опасно.
А разве не надо для массивов тоже использовать дженерики в этом случае? А то получается что в конечном итоге, получив из массива объект, нужно будет кастить его тип?
Т.е.
public class JsonArray extends JsonElement<List<JsonElement>>
нужно заменить на что-то типа
public class JsonArray<TT> extends JsonElement<List<JsonElement<TT>>>
Или нет?
А чего их искать? Они же и так ищутся, когда файл собирается. Или для доступа к данным поиск как-то магически осуществляется?
Т.е. набор символов, или даже не так. Набор байт, который представляет собой доменное имя регистрирует компания (звучит зловеще, давайте называть ее Вейланд Ютани), и поэтому этот набор плохо. А набор байт, который представляет собой нейкий "идентификатор" появляется от святого духа и сам мнеджет себя от дубликатов и прочих проблем. А главное, никаких компаний...
Ну ок.
Фиерично :)
Ладно, я видимо не понимаю чего то :)
Грандиозно, ничего не скажешь. Для начала не мешало бы с покрытием Земли закончить. Хотя, тут может Старлинк через какое-то количество лет раздуплится...
Т.е. в некую систему собираются запихивать данные с кучи планет (ну дизайн системы я так понимаю на это рассчитан) без возможности удаления... Хм... А хранилище не лопнет?
А чем "идентификатор" принципиально отличается от связки доменного имени и имени файла? Я так понимаю тут ноги из линкуса растут с его фаловыми нодами... Ну так они там регулярно заканчиваются.
Что значит не на какой-то конкретный узел? Т.е. что бы собрать файл поедино надо какой-то нетривиальный квест пройти? Или все-таки известно где и какая его часть лежит? Тогда в чем проблема удалить? Ну кроме административных препон, которые можно обойти или взломать. Это я к "принципиальной невозможности".
Отлично. Т.е. мы туда не только все подряд будем со всех планет тянуть, у нас еще и 100500 копий всего будет...
Действительно, получается градиозно.
Я один не могу сдержать смех когда читаю "InterPlanetary File System — межпланетная файловая система" :)
Не, я все понимаю, понт дороже всего, но почему тогда не Межгалактическая хотя бы?
Ну серьезно. Даже если это работает именно так, как заявляется, называние вводит в недоумение :)
Даешь comment driven development! :)
В каком смысле умел? Сам по себе конечно не умеет. Надо небольшую программку написать.
Я имелл ввиду проблемы на которые вы намекали. Типа зависаний.
А есил вместо всего этого просто старый адроид использовать? И ОС и поддержка сетей из коробки прям.
А если вместо модема старый телефон использовать. Ну андроид, например. Тоже все проблемы без watchdog'а будут?
Так просто на этот вопрос не ответить. Много очень зависит от места жительства семейного положения и т.п.
Например, для семьи с одним ребенком и с одним работающим за 100К в MD налоги будут около 20%.
Это то, что вычитается с ЗП. Если есть дом, то отдельно надо будет платить за дом.
Кроме того, есть всякие платежи, которые не являются налогом, например, медицинская страховка. Взносы в "пенсионный" фонд (ну фонда нет, но но специальные счета хорошо бы иметь), стоматологическая страховка, медицинские накопительные счета...
Много чего есть. Часть из этого берется до налогов и у каждого свои суммы получаются. Отчасти от того, что есть много вариантов и опций, отчасти от того, что ты можешь сам выбирать суммы платежей в некоторых случаях, например, на пенсионный счет.
Поэтому всегда говорят о ЗП до налогов.
В среднем, на упомянутую семью, с более-менее нормальной страховкой и не фанатичными платежами на пенсию и медицину (имеется ввиду не плата за лечение, а отчисления на накопительные счета) будет выходить около 30%
Я аж прям колдунства какого-то ожидал :)
Ан нет. Согласен с предыдущем комментарием. И гарантий нет и несколько неудобно может получится, если в неопределенный момент в будущем неконтролируемые запросы вдруг полезут куда-то...