Ага — точно не разглядел годы.
Но вообще ситуация немногим лучше и в динамике.
Все равно экспортируем в разы меньше штатов и всегда меньше Бразилии, Германии и Швейцарии. Импортируем значительно меньше развитых стран запада.
Но вообще это все можно объяснить агрессивными воинами НАТО — вроде как им нужно очень много стрелкового оружия и шмоток постоянно. А у нас пока до него еще не добрались.
С импортом оружия в России тоже все довольно глухо. Объем внешних закупок совершенно мизерный. В десятки раз меньше любой сколь угодно маленькой развитой страны. И это странно учитывая разрушенный ОПК.
А если учесть мизерный экспорт, то все выглядит совсем печально.
Или наша страна находится в сильнейшей экономической блокаде со стороны всего запада, США, Бразилии и Китая в плане закупок оружия. Или, что скорее всего, мы просто вообще не обновляем свое вооружение.
Россия совсем мало оружия продает.
Значительно меньше чем многие другие страны. Даже меньше чем Финляндия, Автралия или Португалия. На порядок меньше чем Англия, Германия, Франция, Испания, Китай Бразилия. И на два порядка меньше чем Штаты. Даже странно.
Ваши оценки вероятности присутствия планет с жизнью не учитывают современной астрономии. Сегодня известно, что Солнце не просто какая то там звезда типа G, а вторичная звезда. То есть она образовалась не во время появления вселенной.
Она содержит в своем спектре тяжелые элементы, которые образуются только при взрывах сверхновых. Таких звезд офигенно мало.
То есть сегодня мы знаем что наша звездная система очень не типична.
В типичных системах по видимому планеты земного типа даже не могут образоваться.
В них нет ничего кроме гелия и водорода.
Что касается жизни с использованием каких то других элементах в других условиях, то такой жизни никто никогда не наблюдал и серьезных оснований полагать что она возможна нет. Все это фантастика.
Пока что мы считаем, что для зарождения жизни нужны хотя бы несколько минимальных условий, которые есть на Земле, но нет на Марсе и Венере.
Так что все намного хуже чем Вы тут описываете. Пусть наука занимается этим, а Вы — просто пожинайте ее плоды, а не оценивайте ее истинность.
Конечно было бы круто сделать авторизацию в яндексе.
Многие пользователи яндекс фоток не делают все фотографии публичными.
В тоже время иногда самому хочется их пересмотрет.
Реализация не сложная.
Странно что сразу не сделали.
По современным моральным нормам которые отражены в трудовом кодексе — все что относится к «предпринимательским рискам», будь то недополученная прибыль, кассовые разрывы и даже проблемы вызванные некомпетентностью сотрудника, это проблема организации, а не наемного работника.
И все что обещано сотруднику по договору и закону не должно зависеть от таких вещей. То есть все эти проблемы должна решать компания в рамках своих процедур, но риски не должны ложится на наемного работника в виде поощрений-урезаний зарплаты, задержек и т.д.
Получается, что если мы говорим только о нормальных организациях, которые следуют законам и моральны нормам, принятым в обществе, а не о всяких быдлоконторках, то наемный работник реально зависит только от одной возможной проблемы компании — ее ликвидации.
Все остальные его риски — будь то риск увольнения, порицания, лишения премии и т.д. не зависят от того, как в компании идут дела.
Софтверная разработка в рамках использованных Вами технологий требует большого количество специальных знаний по использованию фреймворков и высокого уровня организации разработки в архитектурном плане.
Все знают что нативные api для windows восновном не являются интуитивно понятными и там нет никакой защиты от «дурака». Вообще там нельзя полагаться на здравый смысл, только на документацию и стиль уже написанного, работающего кода.
Наймите себе хорошего архитектора, который уже все Ваши проблемы проходил.
И пусть все пишут код в рамках того стиля, который он создаст.
Думаю автор не хотел сказать, что файлы должны удалится мгновенно.
Ситуация в которой функция возвращает положительный ответ на запрос удаления до фактического удаления файла может быть нормальной.
Но только в том случае, если для всех последующих вызовов в рамках использованного API система будет вести себя так, как будто файл удален.
В противном случае это явный косяк системы.
Это не трудно реализовать: можно например при создании файла на месте недоудаленного заставить поток ожидать окончания его удаления или еще как нибудь.
С какого перепугу если я удалил файл и мне сообщили что функция удаления выполнена успешно, на поверку оказывается что это сущая ложь?
И вокруг этой лжи приходится накручивать воркэраунды.
А можно к подобным динамикам подключить несколько устройств одновременно или быстро переключаться между устройствами?
Никто не в курсе?
Было бы здорово если бы можно было придя домой быстро включить музыку с телефона, а потом включить фильм на компьютере и чтобы он уже к нему сразу подключился.
Ну и еще чтобы не приходилось покупать по динамику на каждый лэптоп в квартире.
Все таки мне кажется что будущее за поддержанием профиля пользователя вместо вбивания своих контактных данных каждый раз. Вон в paypal всегда есть твои контактные данные и интернет магазины их могут использовать. Может и yandex market эту тему разовьет.
Кстати интересно, какой процент заказа поступает у вас через такие формы по сравнению с заказами залогиненных покупателей?
Тут еще не сказали что ssd в отличие от hdd не шумит, не греется и ему не страшны падения и удары.
Даже не сомневайтесь, ssd сейчас брать целесообразнее.
Сэкономит вам кучу нервов из-за более высокой отзывчивости системы.
Ну — собственно путинг говорит ютубу — вы нарушили персональные данные моего дружбана.
Немедленно удалите ролик где он отдыхает в италии за госсчет — он заслужил поездку.
Ютуб обращается к владельцу ролика и требует удалить запись или персональные данные из записи.
Тот замазывает лица путингского дружбана — все довольны.
Ну попробуйте описать как применить LSP без полиморфизма.
OCP может иметь смысл еще в частных случаях модульной архитектуры, но не в процедурном стиле разработки. Там не предполагается что процедуры будут как то расширятся.
Его придумали для наследования.
Какой смысл имеет SRP без понятия объекта, на котором может быть ответственность (ну для функций и процедур его притянув за уши можно применить — но там он не нужен).
SRP нужен в ООП, где полиморфизм значительно усложняет поведение объекта.
В модульной разработке само понятие модуля уже включает этот принцип.
DIP — теоретически применим опять же в частных архитектурных случаях, потому что базируется на понятии абстракции, которое используется не только в ООП. То есть он работает в модульных архитектурах — но сам принцип там не особо нужен — всместо него есть базовые принципы организации зависимостей.
А вот если есть наследование — то DIP даже обретает смысл как отдельный принцип.
Мы пытаемся дать определение ООП — при чем тут термины.
Я предложил аксиоматику сказав, что данное Вами определение неверно.
Вы можете привести аргументы, опровергнув мое мнение или согласится с ним.
MVC не омеет отношения к ООП на мой взгляд. Это более общий паттерн.
Принципы SOLID никакого концептуального значения не имеют — это чисто ОО паттерны и за пределами ООП полностью теряют смысл.
Возьмите любую задачу, которая решается в рамках процедурного стиля — например создание клиентонезависимого API какого нибудь сервиса в интернете (не restful) и попробуйте применить SOLID — все эти принципы или потеряют смысл или будут работать с точностью до наоборот.
Более того, объектно-ориентированные языки сами зачастую нарушают правило инкапсуляции, предоставляя доступ к данным через специальные методы — getters и setters в Java, properties в C# и т.д.
По поводу языка — ну ок — будем считать что язык обьектно ориентируюемый — если парадигма ООП в нем доминирующая.
В C можно и передавать в функции в явном виде указатель на объект — тогда он еще больше станет похож на объект из ООП. Ну если этот пример Вам не нравится — возьмите там DTO объект например — у них тоже нет полиморфизма — это разве ООП стиль?
Что касается Haskell — вот тут вроде описано как разрабатывать в рамках ООП с его помощью.
Что касается ссылки на Алана Кея, Вы совершенно верно заметили, что общепризнанного определения ООП еще нет. А Алан так вообще писал что то сильно заточенное под смоллток.
Лично я считаю, что наиболее подходящее в данный момент определение, это выполнение принципов полиморфизма, инкапсуляции и наследования.
Эта аксиоматика полная и в ней нет ничего лишнего.
И в данный момент это наиболее распространенное определение.
Его популяризировал Страуструп, как раз когда C++ стал тем, как мы сегодня представляем себе классический ОО язык.
Все паттерны и подходы в ООП проистекают из этих трех основопологающих принципов, а вовсе не из понятия объектности.
Но вообще ситуация немногим лучше и в динамике.
Все равно экспортируем в разы меньше штатов и всегда меньше Бразилии, Германии и Швейцарии. Импортируем значительно меньше развитых стран запада.
Но вообще это все можно объяснить агрессивными воинами НАТО — вроде как им нужно очень много стрелкового оружия и шмоток постоянно. А у нас пока до него еще не добрались.
А если учесть мизерный экспорт, то все выглядит совсем печально.
Или наша страна находится в сильнейшей экономической блокаде со стороны всего запада, США, Бразилии и Китая в плане закупок оружия. Или, что скорее всего, мы просто вообще не обновляем свое вооружение.
Значительно меньше чем многие другие страны. Даже меньше чем Финляндия, Автралия или Португалия. На порядок меньше чем Англия, Германия, Франция, Испания, Китай Бразилия. И на два порядка меньше чем Штаты. Даже странно.
Она содержит в своем спектре тяжелые элементы, которые образуются только при взрывах сверхновых. Таких звезд офигенно мало.
То есть сегодня мы знаем что наша звездная система очень не типична.
В типичных системах по видимому планеты земного типа даже не могут образоваться.
В них нет ничего кроме гелия и водорода.
Что касается жизни с использованием каких то других элементах в других условиях, то такой жизни никто никогда не наблюдал и серьезных оснований полагать что она возможна нет. Все это фантастика.
Пока что мы считаем, что для зарождения жизни нужны хотя бы несколько минимальных условий, которые есть на Земле, но нет на Марсе и Венере.
Так что все намного хуже чем Вы тут описываете. Пусть наука занимается этим, а Вы — просто пожинайте ее плоды, а не оценивайте ее истинность.
Многие пользователи яндекс фоток не делают все фотографии публичными.
В тоже время иногда самому хочется их пересмотрет.
Реализация не сложная.
Странно что сразу не сделали.
И все что обещано сотруднику по договору и закону не должно зависеть от таких вещей. То есть все эти проблемы должна решать компания в рамках своих процедур, но риски не должны ложится на наемного работника в виде поощрений-урезаний зарплаты, задержек и т.д.
Получается, что если мы говорим только о нормальных организациях, которые следуют законам и моральны нормам, принятым в обществе, а не о всяких быдлоконторках, то наемный работник реально зависит только от одной возможной проблемы компании — ее ликвидации.
Все остальные его риски — будь то риск увольнения, порицания, лишения премии и т.д. не зависят от того, как в компании идут дела.
Все знают что нативные api для windows восновном не являются интуитивно понятными и там нет никакой защиты от «дурака». Вообще там нельзя полагаться на здравый смысл, только на документацию и стиль уже написанного, работающего кода.
Наймите себе хорошего архитектора, который уже все Ваши проблемы проходил.
И пусть все пишут код в рамках того стиля, который он создаст.
Ситуация в которой функция возвращает положительный ответ на запрос удаления до фактического удаления файла может быть нормальной.
Но только в том случае, если для всех последующих вызовов в рамках использованного API система будет вести себя так, как будто файл удален.
В противном случае это явный косяк системы.
Это не трудно реализовать: можно например при создании файла на месте недоудаленного заставить поток ожидать окончания его удаления или еще как нибудь.
С какого перепугу если я удалил файл и мне сообщили что функция удаления выполнена успешно, на поверку оказывается что это сущая ложь?
И вокруг этой лжи приходится накручивать воркэраунды.
Никто не в курсе?
Было бы здорово если бы можно было придя домой быстро включить музыку с телефона, а потом включить фильм на компьютере и чтобы он уже к нему сразу подключился.
Ну и еще чтобы не приходилось покупать по динамику на каждый лэптоп в квартире.
Кстати интересно, какой процент заказа поступает у вас через такие формы по сравнению с заказами залогиненных покупателей?
Даже не сомневайтесь, ssd сейчас брать целесообразнее.
Сэкономит вам кучу нервов из-за более высокой отзывчивости системы.
Чет я не понял — получается можно только один такой пароль запомнить?
А если запомнить два — то первый может и не сработать?
Немедленно удалите ролик где он отдыхает в италии за госсчет — он заслужил поездку.
Ютуб обращается к владельцу ролика и требует удалить запись или персональные данные из записи.
Тот замазывает лица путингского дружбана — все довольны.
Теперь будут на ютубе ролики, на которые неизвестное лицо вбрасывает бюллетени на выборах и катается по италии.
OCP может иметь смысл еще в частных случаях модульной архитектуры, но не в процедурном стиле разработки. Там не предполагается что процедуры будут как то расширятся.
Его придумали для наследования.
Какой смысл имеет SRP без понятия объекта, на котором может быть ответственность (ну для функций и процедур его притянув за уши можно применить — но там он не нужен).
SRP нужен в ООП, где полиморфизм значительно усложняет поведение объекта.
В модульной разработке само понятие модуля уже включает этот принцип.
DIP — теоретически применим опять же в частных архитектурных случаях, потому что базируется на понятии абстракции, которое используется не только в ООП. То есть он работает в модульных архитектурах — но сам принцип там не особо нужен — всместо него есть базовые принципы организации зависимостей.
А вот если есть наследование — то DIP даже обретает смысл как отдельный принцип.
Я предложил аксиоматику сказав, что данное Вами определение неверно.
Вы можете привести аргументы, опровергнув мое мнение или согласится с ним.
MVC не омеет отношения к ООП на мой взгляд. Это более общий паттерн.
Принципы SOLID никакого концептуального значения не имеют — это чисто ОО паттерны и за пределами ООП полностью теряют смысл.
Возьмите любую задачу, которая решается в рамках процедурного стиля — например создание клиентонезависимого API какого нибудь сервиса в интернете (не restful) и попробуйте применить SOLID — все эти принципы или потеряют смысл или будут работать с точностью до наоборот.
Более того, объектно-ориентированные языки сами зачастую нарушают правило инкапсуляции, предоставляя доступ к данным через специальные методы — getters и setters в Java, properties в C# и т.д.
В C можно и передавать в функции в явном виде указатель на объект — тогда он еще больше станет похож на объект из ООП. Ну если этот пример Вам не нравится — возьмите там DTO объект например — у них тоже нет полиморфизма — это разве ООП стиль?
Что касается Haskell — вот тут вроде описано как разрабатывать в рамках ООП с его помощью.
Что касается ссылки на Алана Кея, Вы совершенно верно заметили, что общепризнанного определения ООП еще нет. А Алан так вообще писал что то сильно заточенное под смоллток.
Лично я считаю, что наиболее подходящее в данный момент определение, это выполнение принципов полиморфизма, инкапсуляции и наследования.
Эта аксиоматика полная и в ней нет ничего лишнего.
И в данный момент это наиболее распространенное определение.
Его популяризировал Страуструп, как раз когда C++ стал тем, как мы сегодня представляем себе классический ОО язык.
Все паттерны и подходы в ООП проистекают из этих трех основопологающих принципов, а вовсе не из понятия объектности.