Как сейчас помню, про это писали в переводной научно-популярной книге про домашние компьютеры издания конца 80х.
Книга, кстати, была бомбезная — в 200-300 страницах было всё: от советов по покупке (ну, применительно к британским реалиям, конечно :) ) до азов программирования
В Харькове в самом начале 90х экспериментировали с трансляцией программ для Спектрума через звуковой канал телепередач. Вначале «передавали» популярные игры, а затем запилили собственную рекламно-информационную программку и транслировали её
Ну дык… время такое было — мода на ООП везде и всюду. Помню, тогда даже ходили разговоры о создании полностью нового объектно-ориентированного WinAPI (полагаю, именно оттуда и «растут ноги» у WinRT)
языки у МС получаются на удивление неплохо (тот же typescript)
Если, точнее, то у Андерса Хэйлсберга, которому мы благодарны за Turbo Pascal, Delphi, C# и TypeScript :)
Заслуга МС тут только в том, что вовремя подсуетились его нанять.
Полагаю, waltter о том, IE нельзя просто так взять и выпилить из операционки (в отличие от Хрома или Огнелиса, которые просто удаляются как и любое другое стороннее приложение), потому что немало динамических библиотек IE используются другими компонентами системы и, что хуже, сторонними приложениями.
В новый нельзя :( Вернее, сообщения за последний год новый и так подтянет с серверов, а более старые можно смотреть только специальными приложениями наподобие SkypeLogView
которые они проигнорируют, как сообщения об удалении пользовательских файлов последним обновлением винды, о чем писали инсайдеры на специальном портале
Ну, вообще-то, справедливости ради, массовое распространение этого обновления приостановили именно благодаря сообщениям от инсайдеров.
Мне кажется, вот это ключевой вопрос в дискуссии, потому что потребности у всех разные :)
Я сам лет 8-10 назад активно пользовался Paint .NET для простых задач из серии «обрезать картинку» или «дорисовать стрелочку к кнопочке». А потом как-то пришёл к тому, что для более сложной обработки фотографий Paint .NET не подходит, да и рисовать в нём что-то сложнее стрелочек и рамочек не сильно удобно. Вот и пришлось осваивать Inkscape и GIMP, потому что потребности переросли инструмент.
С другой стороны, GIMP и Inkscape неудобны тем, что медленно запускаются, и для простых операций действительно было бы удобно иметь под рукой нечто более легковесное. А в этой весовой категории, видимо, у Paint .NET нет конкурентов.
Я давно не следил за этим продуктом, и наличие сторонних плагинов к нему — для меня действительно новость. Порекомендуете, пожалуйста, стоящие?
Я не автор, но рискну утверждать, что автор не перепутал. В случае MVP крайне редко (если вообще) в самом начале разработки есть хоть какое-нибудь чёткое понимание того, что получится в итоге. Поэтому архитектура, которая казалось наиболее подходящей в, скажем, первые пару месяцев разработки, затем, в один прекрасный момент, может превратиться в «палку в колесе», когда выяснится, что на её основе сложно и дорого реализовать бизнес-требование, появившееся буквально вчера после очередной встречи с потенциальным покупателем продукта.
Поэтому в MVP, как нигде, «рулит» принцип минимально достаточной архитектуры и постоянного перепроектирования из Extreme Programming.
Возникает большой соблазн превратить UIContoller в анти-паттерн «god class». Как вам правильно заметили выше, это сильно усложняет покрытие кода тестами, и ухудшает такой важный для последующей поддержки кода параметр, как связность (coupling)
И дело не в передаче данных между экранами, а в том, что постепенно на UIController навешиваются обязанности заниматься чем угодно, что является грубым нарушением single responsibility principle.
Что такое изолированность слоёв я не понял
Я бы посоветовал поискать материалы на тему «луковой» архитектуры (onion architecture). Она хоть и придумывалась изначально для бэкенда, но даёт общее представление о том, какие бывают слои, и как их правильно изолировать.
Поправьте, пожалуйста, если ошибаюсь, но кажется, что все альтернативные варианты, кроме progressive web apps, так или иначе, требуют MacOS и Xcode для того, чтобы на выходе получилось мобильное приложение, работоспособное на настоящем iPhone / iPad.
На всякий случай дополню, что React Native — это совсем НЕ то же самое, что PhoneGap и ему подобные решения. По сути, React Native всего лишь:
позволяет использовать JavaScript как язык программирования вашего мобильного приложения
даёт удобные биндинги к API мобильной платформы
позволяет описывать пользовательский интерфейс с помощью похожей (но только похожей) на HTML разметки
Никаких web view и HTML/CSS по умолчанию в React Native приложении нет.
С другой стороны, идея сделать что-то в духе angular-material для мобильной платформы, чтобы интерфейс всех экранов и внешний вид элементов управления соответствовали «фирменному стилю» — совершенно здравая идея, позволяющая ещё и экономить на решении прикладных задач путём многократного переиспользования конструктора.
React Native в том и хорош, что даёт лучшее из двух миров — возможность программировать пользовательский интерфейс в знакомой парадигме React / Redux с очень похожим на HTML5 языком разметки, при этом на выходе получается полностью нативное приложение безо всяких WebView.
У меня первым в детстве был конструктор, который, судя по картинке, как раз совместим с немецким. Вы совершенно правы, т.к. этот вариант был, как раз, далеко не самым ходовым в СССР, хотя по качеству исполнения деталей был несколько лучше.
А самый ходовой появился у меня несколько позже и-таки был несовместим с первым набором.
Складывается ощущение, что все эти дыры в безопасности — не плод плохого программного кода, а запланированный ход.
В данном случае, это очень вряд ли «закладка». Протокол SMBv1 был дырявым с самого начала, но, не по злому умыслу, а тупо потому, что, когда его разрабатывали (а это, на минуточку, самое начало 90х), Интернета в современном понимании ещё не было, и авторы вполне справедливо предполагали изолированную от внешнего мира локальную сеть, работающую по собственным протоколам MS. Прикручивание SMBv1 к TCP происходило позже, и, видимо, в спешке, в погоне за Sun с их WebNFS.
то есть получается заражение было возможно только у компов сидящих через мобильные «свистки» ?
Первичное заражение — да. Но, достаточно заразить один такой компьютер, и, если у него есть второй сетевой интерфейс, «смотрящий» в локалку — то зараза быстро полезет по всей сети.
«Прятать шляпу» — это святое :) Правда, есть особо въедливые заказчики, эдакие control freak'и, которые сами перепроверяют чуть ли не каждую строчку в коде, и, если, например, увидят там юнит-тест, хотя сами говорили «юнит тесты не пишем» — жди скандала.
есть некий документ DoD, который описывает критерии качества для backlog item'а. Что внесёт в DoD команда — полностью на её совести.
Ах, если бы это было так! В реальности, зачастую бывает совсем по-другому, и вовсе не потому, что команда не умеет «готовить» Scrum. А потому, что качество — это просто ещё одна из характеристик создаваемого программного продукта, и далеко не всегда заказчик готов платить за решение, сделанное полностью «по фэншую».
Книга, кстати, была бомбезная — в 200-300 страницах было всё: от советов по покупке (ну, применительно к британским реалиям, конечно :) ) до азов программирования
Если, точнее, то у Андерса Хэйлсберга, которому мы благодарны за Turbo Pascal, Delphi, C# и TypeScript :)
Заслуга МС тут только в том, что вовремя подсуетились его нанять.
Ну, вообще-то, справедливости ради, массовое распространение этого обновления приостановили именно благодаря сообщениям от инсайдеров.
Мне кажется, вот это ключевой вопрос в дискуссии, потому что потребности у всех разные :)
Я сам лет 8-10 назад активно пользовался Paint .NET для простых задач из серии «обрезать картинку» или «дорисовать стрелочку к кнопочке». А потом как-то пришёл к тому, что для более сложной обработки фотографий Paint .NET не подходит, да и рисовать в нём что-то сложнее стрелочек и рамочек не сильно удобно. Вот и пришлось осваивать Inkscape и GIMP, потому что потребности переросли инструмент.
С другой стороны, GIMP и Inkscape неудобны тем, что медленно запускаются, и для простых операций действительно было бы удобно иметь под рукой нечто более легковесное. А в этой весовой категории, видимо, у Paint .NET нет конкурентов.
Я давно не следил за этим продуктом, и наличие сторонних плагинов к нему — для меня действительно новость. Порекомендуете, пожалуйста, стоящие?
Поэтому в MVP, как нигде, «рулит» принцип минимально достаточной архитектуры и постоянного перепроектирования из Extreme Programming.
И дело не в передаче данных между экранами, а в том, что постепенно на UIController навешиваются обязанности заниматься чем угодно, что является грубым нарушением single responsibility principle.
Я бы посоветовал поискать материалы на тему «луковой» архитектуры (onion architecture). Она хоть и придумывалась изначально для бэкенда, но даёт общее представление о том, какие бывают слои, и как их правильно изолировать.
Никаких web view и HTML/CSS по умолчанию в React Native приложении нет.
С другой стороны, идея сделать что-то в духе angular-material для мобильной платформы, чтобы интерфейс всех экранов и внешний вид элементов управления соответствовали «фирменному стилю» — совершенно здравая идея, позволяющая ещё и экономить на решении прикладных задач путём многократного переиспользования конструктора.
А самый ходовой появился у меня несколько позже и-таки был несовместим с первым набором.
В данном случае, это очень вряд ли «закладка». Протокол SMBv1 был дырявым с самого начала, но, не по злому умыслу, а тупо потому, что, когда его разрабатывали (а это, на минуточку, самое начало 90х), Интернета в современном понимании ещё не было, и авторы вполне справедливо предполагали изолированную от внешнего мира локальную сеть, работающую по собственным протоколам MS. Прикручивание SMBv1 к TCP происходило позже, и, видимо, в спешке, в погоне за Sun с их WebNFS.
Первичное заражение — да. Но, достаточно заразить один такой компьютер, и, если у него есть второй сетевой интерфейс, «смотрящий» в локалку — то зараза быстро полезет по всей сети.
Ах, если бы это было так! В реальности, зачастую бывает совсем по-другому, и вовсе не потому, что команда не умеет «готовить» Scrum. А потому, что качество — это просто ещё одна из характеристик создаваемого программного продукта, и далеко не всегда заказчик готов платить за решение, сделанное полностью «по фэншую».