Pull to refresh
-1
0
Send message
Для того, чтобы говорить, что и как надо было сделать — надо обладать полным пониманием того, что делает система во время полёта. А заодно, неплохо бы знать историю разработки, потому что технические решения это всегда продукт условий и ограничений, в которых их создают.
А рассуждать «как надо» обладая полной информацией об ошибке, это откровенный моветон. У любого человека в жизни можно найти ситуации, когда обладая послезнанием/всей полнотой информации становится ну совершенно очевидно, что так делать не надо.
Вот когда какой-то из проектов вашей фирмы возьмут через 20 лет после сдачи, и запустят в условиях, про которые вы и догадываться не могли на момент проектирования, об этом можно будет говорить.
А кто виноват тоже обозначено — не была проведена проверка имевшегося алгоритма с новыми условиями запуска. Но это уже вопрос интеграции, а не изначального проектирования\исполнения работы на местах, зоны ответственности разные.
Там скорее вопрос будет — «Мама, почему мне есть нечего» — «Папе негде работать, его роботы заменили».
Проблема-то серьёзнейшая, и в какой-то перспективе может коснуться любого человека.
Кажется, вы про разные ситуации.
Вы говорите о ситуации, когда вопрос выживания всех граждан не стоит — ресурсов достаточно, но поскольку бесплатно ничего делать нельзя, без денег всё встаёт.
А товарищ говорит о ситуации, когда ресурсов в некоторых местах совсем нет — ни за деньги, ни без. И в этой ситуации надо доставлять ресурсы, потому что деньгами человека накормить не получится. А использовать для обогрева тоже странно.
В таком случае получается, что это было неизвестно американской разведке.
Либо, что она специально игнорировала эти данные.
Мне кажется, уровень подготовки американских разведчиков исключает подобные базовые просчёты.
Имея некоторый бюджет значительно проще оказаться «в то время, в том месте».
Это не исключает таланта. Это говорит о том, что только таланта и упорного труда — чаще всего недостаточно.
Сразу возникает несколько вопросов:
1) Что с эффективностью в других странах? Давайте сравним с терактами 11 сентября, например.
2) Кем заменять будем?
3) Точно знаем, кто виноват?
Ну и у меня, например, нет достаточных знаний, чтобы оценивать профессионализм, ситуацию, и что можно было сделать. Плюс при оценке надо выключать эффекты послезнания, и оценивать действия с точки зрения информации, доступной в тот момент.
P.S. Про «любого вычислим» — это не правда. В первом посте речь о другом — простые средства безопасности хороши до того момента, пока лично вами не заинтересовались. Собственно, в этом случае человек и является «неуловимым Джо».
На меня в этом треде тоже кто-то обиделся. Хотя, судя по плюсам к комментариям, карма наоборот должна была бы пойти вверх ).
Всесильных структур не бывает. Мало того, ФСБ это не однородная структура, с серьёзной грызнёй внутри. Это, однако, не говорит что они не могут достать конкретного человека, про которого они знают.
Проблема с террористами в том, что потенциально им может стать любой человек. А установить эффективную слежку за всеми невозможно. Поэтому остаётся агентурная работа. А так их периодически ловят. И желающих совершать теракты у нас априори не мало (Кавказ, Узбекистан-Таджикистан — всё рядом), не ловили бы, теракты случались бы сильно чаще.
По комментариям — а чего вы ждёте? Вот какие надо давать комментарии, чтоб в них с одной стороны был смысл, а с другой стороны бандиты не могли это использовать? Оно только на уровне отчётов бывает, например за 2016 год доложили о 42 предотвращённых терактов и задержании 898 бандитов (+129 убито). Плюс постоянно мелькают новости о задержанных. Вопросы веры в эти сообщения я оставляю за скобками :).
Тут несколько направлений — общество старательно атомизируют, гражданам внушают список шаблонных страшилок (при чём про то же ГБ — граждане вообще не понимают, что это и как работает), развлекают и отвлекают. Как результат у большей части мышление на уровне ребёнка: «хорошо» — «плохо», «супергерой» — «злодей».
Зато абсолютная предсказуемость поведения и лёгкость в управлении.
Судя по этому треду, есть много людей, которые верят в непогрешимость Дурова. Также, как верящих в то, что переписка в Телеграмме точно не читается органами.
IMHO Дуров уже давно для многих превратился в эталон борца с системой, и обладает индульгенцией :).
«Объект без поведения» это структура данных, потому что единственный его смысл это хранить данные.
ООП выросло из структурного программирования, и задачей появления объектов было получить управляющую структуру. Т.е. объект нужен, чтобы поддерживать нечто (например, структуру данных) в непротиворечивом состоянии.
Исходя из этого структура данных может являться объектом физически (в терминах C# или Java), но логически это структура данных. Т.е. нормально сконструированный объект должен быть консистентным, а структура данных такого ограничения не имеет.
Этичный человек старается не допустить возможность, когда окружающие могут начать терять достоинство. Потому что этика это во многом следствие обладания умом, а он достаточно чётко показывает, что в нашей реальности люди за деньги готовы совершать чёрти что.
Что и подводит к утверждению, что для таких действий надо не иметь либо ума, либо совести.
Можно ещё оставить людей без еды, а через пару-тройку дней бросить в толпу куски мяса. И после этого порассуждаем о том, какие проблемы это позволяет понять.
А ещё можно просто подумать над значением фразы «сытый голодному не товарищ», а также «бытие определяет сознание».
Та же, что и раньше.
В ситуации, когда изначально предложенная имплементация начинает вам мешать, его стоит заменить на что-то другое.
Например, в небольших домашних проектах использовать синглтон гораздо разумнее, чем пихать туда DI в каком-либо виде.
Visitor — описывает процесс, который не подразумевает мутабельного состояния. Если оно вам необходимо, вы его инкапсулируете, и отдаёте только по результатам работы. Можете его сделать даже иммутабельным, никто не мешает.
Iterator — какую его часть вы называете мутабельным состоянием? А, главное, как вы к нему хотите получить доступ?
MVP — как вы пишете иммутабельный UI, расскажите пожалуйста.

Ну и размытое определение SOLID это пять.
Из моей практики то, о чём вы говорите — было верно на 2010 год. Тогда в ходу действительно была в основном анемичная модель Кстати, по моим воспоминаниям Фаулер в своём PoEA вполне себе описывал целиком ту модель, которую вы сейчас с восторгом описываете. Это 2002 год, если что.
Я бы сказал, что именно в последние пару-тройку лет Rich Data Model снова начала набираться популярность, на фоне всяких Domain Driven Design и прочих радостей. Просто то же DDD советуют применять только если у вас высоко профессиональная команда, иначе придётся собирать грабли.
Хотя у того же Фаулера подходы без использования RICH
Это инструмент.
И паттерн — поскольку это повторяющийся элемент проектирования.
Но из-за узких границ применимости, и нежелания людей думать, его долго пихали в те места, где он плохо работает.
А поскольку думать большинству по-прежнему лень, его «признали плохим».
Микроскоп, кстати, тоже негодная вещь — ей гвозди неудобно заколачивать.
Для каких паттернов мутабельность является неотъемлимым свойством?
Как SOLID мешает вам писать нормальный код в средненькой по размеру команде?
Почему вы считаете, что только у вас есть опыт работы в такой ситуации — или что он у всех отрицательный?
Вы считаете, что в спецслужбах работают сплошь умные и преданные делу люди? Судить по заявлениям каких-либо лиц о том, к чему имеют доступ спецслужбы, мне кажется, не самый правильный подход.
Вообще, я бы не стал сильно рассчитывать на секретность переписки в каком-либо мессенджере. У меня был знакомый, имевший сложные отношения с ГБ. И начать можно с того, что за ним периодически велась слежка, а телефонов у человека было штук 5 (с разными симками, купленными разными бомжами, которые периодически менялись). Это, замечу, не лидер оппозиции и не великий бандит.
В общем, телеграмм это отличная штука для неуловимого Джо. Если вы кому-то понадобитесь, то разбираться с вами будут по-другому.

Information

Rating
Does not participate
Date of birth
Registered
Activity