Pull to refresh
-5
0
Денис И. @dplsoft

Системный Аналитик / Разработчик Java / etc…

Send message

Урра! теперь моё "дергание лапкой" - вовсе не невротическое расстройство, а врожденный способ похудания! йухху! )))

"...сервисы можно оплачивать не только в айосе, но и в вебе "
- у Тима Суини, помнится, были похожие мысли.

Ну, и как там дела, у "Фортнайт под иос" ? Играете? ))

"К тому же на андроиде приложения подсанкционных банков тоже выпиливают."
- вы зачем "забываете", что это только гугль выпиливает ?

Для андроида - есть еще Самсунг-стор, Магазинчик хуавея, банальные apk с сайта сбера... в общем куча альтернатив.

ВТБ и Сбер прекрасно "переустаналиваются в один клик" из самсунговского магазина, даже настройки менять не надо. Я так и сделал, например.

А под яблоко - эппл-магазин - это вообще единственный способ распространять своё приложение. Нет в ябломагазине - нет вообще нигде. Так что ваше сравнение - совершенно не к месту.


Вопрос : как выводить деньги из экосистемы эппл?

Зачем разрабатывать под эппл, если вывести деньги - проблемно. У меня платеж от яблока 2 месяца назад не прошел. Да, это была альфа, но у них не только альфа под санкциями. Почему об аспекте вывода денег из яблостора никто из "экспертов" не удосужился вспонить?

Ну и делать приложения под 10% пользователей, которые хотя может быть и могут тебе хорошо заплатить, но не могут - "такая себе идея".

Вот вам и ответы на вопрос "что будет с иос-разработкой под яблоко" в РФ.

Или кто знает в какой (не иностранный) банк можно выводить деньги за проданные в яблосторе приложения?

Похоже, в "текущей версии настоящего" есть решение в отношении dot-файлов.

Переименуйте все dot-файлы

не знаю что там с генерацией архетипа из существующего проекта, и как оно было ранее, или на момент написания статьи, но на текущий момент dot-файлы, будучи размещенными в ресурсах архетипа, успешно обрабатываются, копируются и через шаблон обрабатываются.

Однако, похоже есть хитрость: в дефолтный pom-ник архетипа надо внести некоторые правки - указать конкретные версии плагинов. Вот фрагмент используемого мною pom.xml проекта архетипа:

	<build>
		<extensions>
			<extension>
				<groupId>org.apache.maven.archetype</groupId>
				<artifactId>archetype-packaging</artifactId>
				<version>3.1.1</version>
			</extension>
		</extensions>

		<plugins>
			<plugin>
			    <groupId>org.apache.maven.plugins</groupId>
			    <artifactId>maven-archetype-plugin</artifactId>
			    <version>2.2</version>
			</plugin>
			<plugin>
			    <groupId>org.apache.maven.plugins</groupId>
			    <artifactId>maven-resources-plugin</artifactId>
			    <version>2.6</version>
			 </plugin>
		</plugins>

	</build>

Соответственно, после этого начинают работать указания на dot-файлы и dot-каталоги : привожу фрагмент файла archetype-metadata.xml для шаблона проекта под эклипс - каталог ".settings" и файлы описания проекта :

<fileSet filtered="true" packaged="false" encoding="UTF-8">
      <directory></directory>
      <includes>
         <include>.classpath</include>
         <include>.project</include>
     	</includes>
</fileSet> 
<fileSet filtered="true" packaged="false" encoding="UTF-8">
      <directory>.settings/</directory>
      <includes>
         <include>**/*.*</include>
      </includes>
</fileSet>

Соответственно, вся дополнительная морока с переименованием dot-файлов отпадает, как минимум на этапе создания проекта из архетипа.

Я, кстати, писал в техподдержку Тинькофф про "странные" значения в графе "среднее".

Их "среднее" - это среднее по цене имеющихся в портфеле акций, но проблема в том, что себестоимость акций списывается по FIFO. В итоге и получается, что их "среднее" - это филькина грамота.

Но техподдержка считает что "всё норм", потому что, (цитата) "налоговая считает прибыль по FIFO".

Аргументы о том, что такой "индикатор", который они показывают на графике, по которому они считают "прибыль" вреден и, по сути, вводит в заблуждение - техподдержку не впечатлили.

Я запросил создать "запрос на доработку" о введении индикатора, который мог бы показывать "себестоимость акций по 'бухгалтерскому' среднему", но не уверен что меня услышали - потому мне ответили что "они внутри обсуждают возможность указывать какие акции надо продавать из портфеля". На мой взгляд, решение... странное. очень.

Вот такие дела.

По сути, на введение адекватного "среднего", на которое можно ориентироваться для принятия решения о продаже/покупке - в рамках стандартного тинькоффского терминала - думаю, можно не надеяться.

Имхо, ситуация "такая себе" и двоякая. С одной стороны - это, фактически, посыл вида "жричодают". С другой стороны - они вроде как дают апи - в контексте вышеописанного превращается в "не нравится? - иди и пиши свой софт". Ну... мы не гордые. Мы свой софт напишем, что делать то... не смотреть же на текущее совершенно глупое "среднее" ?))

Вообще, сама концепция заявлять что "вот у нас, публичных, тут всё зашифровано, а вот у них там - ничего и не разу..." попахивает дурным тоном. Я бы даже сказал политотой и дешевым "желтым маркетингом".

Потому что если хотите действительно секретной переписки, то пользоваться распространенными мессенджерами скачанными из гугле/плеймаркета ... мне одному кажется это идиотизмом? Вся надежда при таком раскладе - только что боты оных служб не нащупают ваши "переговоры" в общей массе, потому что, может быть, вы будете вести "иносказательную переписку", по "заветам старой школы ведения переговоров в открытом радиоэфире"... не находите?

Хотите секретности? Берите опенсорс, перепиливайте. Или, хотя бы, пользуйте tox. p2p, асиметричное шифрование, общаетесь только с теми, с кем вы обменялись ключами, утеря секретного ключа - означает потерю аккаунта. Навсегда. Без возможности восстановления доступа. Всё как завещали адепты шифрования.

При впиливании в пересобранную софтину "усиленного шифрования" - отвечайте еще и за нарушения местного законодательства о применении средств шифрования. Но если у вас были основания идти таким серьезным путем - то нарушение законодательсва о шифровании - это будет наименьшая из ваших проблем когда вас поймают, ведь так?)))

А вот эти все малограмотные разговоры по "шифрование в публичных распространенных мессенджерах"... Я вас умоляю. Сказки для глупых. Драка песочными лопатками - слезы, крики, ругань, шум... а смысл - только в рекламе. Пустословный срач в сми за аудиторию хомячков, которые не понимают, ни чем кодирование отличается от асиметричного шифрования, ни для каких целей применяются те или иные средства шифрования.

Сам по себе исходный пост основателя Signal - это вброс на вентилятор, который уже показывает его самого в дурном, желто-коричневом свете. Но своей цели он добился - я вот был не в курсе что "мессенджер сигнал" как таковой вообще существует. Теперь знаю. Правда, оно автоматически попадает в "личный бан-лист", как "поделие дурных менеджеров".

вы (снова?) смешиваете 2 разных кейса -
(а) защита самого организма от последствий радиации
(б) фильтрация потока излучения

белки организма - вполне успешно могут работать в кейсе (а), потому что это биохимия и биологические процессы - такие как воспроизводство днк, рнк, контроль химических процессов происходящих в клетке, восстановление поврежденных участков днк и пр. При этом меланин присутствует по всему организму, например и в головном мозге - и что он там делает - вроде как не понятно. И если рассматривать гипотезу, что меланин участвует в процессах устранения последствий воздействия ионизирующего излучения - то он действительно должен быть распространен по всему организму. Потому что рентгеновское излучение например - пронизывает организм насквозь, и повреждает белки в клетках по всему организму.

в кейсе (б) меланин - как особый белок - работать не будет - потому что это уже физика. вернее - он способен что-то делать, то только для "мягких вариантов" - для ультрафиолета и (возможно) частично для рентгеновского излучения.


___________________________

Статья которая легла в основу вашего поста - намекает на роль меланина в кейсе "Б" ( цитата: "Было постулировано, что поглощение излучения связано с пигментом меланином. Далее выдвигается гипотеза, что это явление приводит к радиационно-защитным свойствам.").

А вы приводите статьи описывающие роль меланина в кейсе "А".

Понимаете нестыковку?

___________________________
меланин если что и может фильтровать - то только ультрафиолет и (похоже) в некоторой степени - рентгеновское излучение (что, как вы понимаете, практически не применимо для ситуации в космосе).

И опять же - в вашей же последней ссылке ("Selenomelanin: An Abiotic Selenium Analogue of Pheomelanin") говорится о гипотетическом "селеномеланине" - в котором присутствуют атомы селена. т.е. - исследователи рассуждают об изменении физических свойств - состава элементов входящих в белок.

т.е. это подтверждение именно того, о чем я и говорил:
"свойства биоматериала задерживать частицы связано не с биологическими процессами в нем происходящими, а с физическими свойствами материала " + "в частности - плотность вещества, размер атомов и пр." (да вероятно я слишком фривольно использую термин "физические свойства" - размер атомов это уже не совсем физические свойства, но суть думаю понятна).

____________________________
Меланин не может выступать как эффективное средство фильтрации от радиации в космосе (кейс Б). В силу физических свойств его самого и клетки в целом. Промышленные "не биологические" материалы куда более эффективны и практичны.

А вот как некий "секретный ингредиент " (в купе с другими элементами ), укол которого поможет космонавтам легче переносить воздействие радиации (кейс А) - это вполне может случиться.

Но это же совсем не тема статьи про грибы. Ведь да?

а я, собственно, всё пояснил. как мне кажется.

свойства биоматериала задерживать частицы связано не с биологическими процессами в нем происходящими, а с физическими свойствами материала 

в частности - плотность вещества, размер атомов и пр.

в статье же фактически утверждается, что "(иносказательно) особые белки, собранные особым образом, защищают от ионизирующего излучения лучше, чем собранные "не особым" образом белки. ". а именно: там постулируется что грибы используют меланин для защиты от ионизирующего излучения. (впрочем это не доказывается).

(*для ультрафиолета это, конечно, как-то работает. но уже для ренгена - это все становится очень сомнительно.).

( ** еще надо понимать, защищают что? сам организм? например улучшать способность клетки находить ошибки в белках или в днк и исправлять их - что бы снизить вред от влияния радиации на биохимию клетки - да могут. но не более)

понимаете? для проникновения ионизирующего излучения (фотоны и чвстицы) сквозь физические преграды - не важно какая у тебя форма молекул, если плотность атомов в пространстве одинакова в обоих случаях. а как ты углерод с кислородом не пересобирай в растворе цитоплазмы клетки - плотность его не сильно изменится. особенно средняя на всю клетку.

отсюда и практическая несостоятельность такого рода защиты - промышленные материалы будут "тупо" иметь бОльшую плотность, чем клетки любого организма.

да даже найти ледяной астероид и "скомкать" из него защиту будет как то наверное быстрее и практичнее. а еще лучше - с точки зрения использования местных материалов - летать внутри каких-нибудь железно-каменных астероидов)) (не уверен)

ps: вообще, самовосстаналиваюшиеся материалы с использованием биотехнологий - тема очень интересная. например сейчас кто то прорабатывает идею бетона, который умеет самозаращивать микротрещины и таким образом сохранять свою целостность и полезные "конструктивные свойства" дольше, чем обычный бетон. но как вы понимаете, к кликбейтному "защита от радиации" это не имеет совершенно никакого отношения.

"Грибы не надо выводить, они вырастут на месте" - ну ведь я же не просто так написал в корневом комментарии что такая грибная защита если и будет где применима - то на планетах. А в вакууме, в космосе - что будет жрать эта грибница? вам надо вытащить на орбиту еще и кучу питатетельных веществ. и да, на какашках такая защита не вырастет - не практично это - космонавт не факт что протянет столько, что бы "накакать веществ" на 2.5 метра вокруг корабля.

ну и а выводить на орбиту питательтные вещества и ждать... ? практичнее вывести на орбиту такую же массу уже готовых элементов радиационной защиты.

ладно. я думаю надо прекращать обсуждение. а статью надо было выпускать на 1 апреля. поторопились.

"как я понял, при попадании высокоэнергетической частицы возникает целый пучок осколков от ядер свинца, который уже накрывает космонавтов по полной" - я не знаю откуда у вас такая информация, (приведите источники?), но в общем случае - она не верна, если мы говорим именно про "некие особенные свойства свинца".

возможно вы придаете конкретно свинцу явление общего характера - вторичная (наведнная) радиоактивность, но это явление характерно для всех веществ и материалов . именно по этой причине в чернобыле существуют "могильники" с техникой которую попросту свезли на площадку и там бросили на ближайие пару тысяч лет (ну или сколько-то там).

"проще использовать банальный полиэтилен" - вы не прикроете полиэтиленом весь спектр излучений и все виды ионизирующих частиц. для полноценной защиты - вам нужен многослойный комплекс, - металл, полиэтилен, вода... в идеале - в купе с дополнительным магнитным полем. "вот это всё" - а не "2.5 метра грибницы".

насчет сложности вывода на орбиту свинца - это все равно будет практиченее. сравните - вывести на орбиту цилиндр с полуметровой толщиной, или цилиндр с 2.5. метровыми стенками из грибов... ? в общем не надо фантазировать. имхо.

свойства организмов использовать радиацию для получения энергии - никоим образом не придает им функции "защиты от радиации".

свойства биоматериала задерживать частицы связано не с биологическими процессами в нем происходящими, а с физическими свойствами материала (ну разве что грибы научатся как то влиять на проходящие сквозь их тела частицы ? - например генерировать магнитное поле? но они же типа пока так не умеют вроде?).

это 2 разных уровня процессов. как минимум, потому, что прохождение радиации через массу вещества - это фактически субатомные процессы, а биологические процессы - это биохимия сложных молекул.

и слой свинца в метр будет защищать едва ли не лучше чем 2.5 метра "грибов".

единственный плюс грибов - это самовосстановоение при поврежлении микрометеоритами, или использование местных ресурсов на другой планете. но для корабля, имхо, это странное и не эффективное решение. метр свинца и "громадная магнитная катушка" дадут лучшую и более практичную с точки зрения выведения на орбиту решение.

в общем статья странная.

отдельно общаю внимание на то, что отчет об оригинальном исследовании - статья по ссылке является препринтом, а не проверенным результатом исследования. будьте осторожны с препринтами. там могут быть методические ошибки, не верные выводы и др.

а, собственно, как совмещать питон и котлин в одном проекте? какова архитектура такого проекта? как огранизована связь между подсистемами / модулями написанными на разных языках? не хочу обижать автора, но заголовок "немного намекает" именно на такое содержимое статьи...

было бы интересно узнать есть ли что-то новое по данному вопросу.

потому что единственное известное мне правильное решение , не менявшееся уже лет 5-8, связанное с "совмещением этих языков", когда надо делать акцент на свойствах этих 2-х языков языков (с моей точки зрения) - ... это какой нибудь JPython. дада "The Java Scripting API", который, я думаю, доступен и в котлине, с помощью которого можно в рантайме, без пересборки менять поведение уже скомпиленной с собранной в байткод системы.

это, имхо, единственный случай, когда нам в принципе важно на каком языке написаны модули, и когла надо рассматривать описанные в статье свойства язвков. ( и если вдруг автор напишет о том, как отлаживать/трейсить скрипты запущенные через "Java Scripting API" - желательно на тестовом стенде или даже проде (если заказчику даны возможности настраиватт скрипты), а не на стенде разработчика - вот это будет очень интересно и соответсвовать названию. имхо.)

во всех остальных случаях, совершенно не важно на каком языке написана подсистема/компонент - важно "как нам увязать эти 2 программы вместе". а будет это на котлине, джаве, питоне, пхп, c++ или ещё как... - это уже совершенно не важно, или это становится проблемой команды которая должна адаптировать этот продукт/решение доя укладки в систему.

имхо.

//кстати, автор не упомянул проблемы рефакторинга больших проектов на языках с динамической типизацией (я видел упоминание про "подсказки в ide", но этою имхо, не очень большой кусочек ситуации), необходимость наличия четко описанного стандарта на язык (привет тебе ruby с движками, работаюшими чуть по разному на разных платформах (поправьте меня? может за 4 года что ть и поменялось?)), и проблемы обратной совместимости, которые могут привести к неработоспособности проекта при попытке сборки на новых версиях компилятора (привет тебе питон 2/ питон 3. и сравните это с качеством обратной совместимости той же java.)

но конечные выводы автора, о разных нишах языков с динамической и статической типизацией - полностью поддерживаю.

>> на "поддержку и развитие" популярного языка программирования ?
вы не верно смотрите на суть вопроса.

задача менеджера - не влиять на стандарт, а иметь стабильный инструмент, за сбой в котором будешь отвечать не он. в случае раста - у нас , как я понимаю, одна команда которая делает компилятор и инструменты, и она же единственная которая готова брать на себя ответсвенность за его сбои или проблемы с безопасностью?

(да я знаю, что сейчас там собирают Rust Foundation, возможно это будет полождительно влиять на ситуацию, но пока про это рано говорить).

Задача менеджера - помимо организации процесса - найти того, на кого он переложит риски)) Иногда это может быть даже "страхование рисков", но чаще - тех поддержка.

И если нет локального представительства - то скорее всего мененджер будет против использования таких инструментов.

Я понимаю, что вы этого возможно не видите. Потому что занимаетесь задачами, цена сбоя в которых - ничтожна. Потому эти риски берет на себя разработчик или админ компании или менеджер. Это "один полюс", так сказать.

И по мере роста цены сбоя - подход меняется, и очень кардинально.

Как противоположенный полюс - можно указать в нашей стране на ЦБ. Т.е. там - вы в принципе не сможете использовать на их проектах, какие либо продукты, если у этих продуктов нет локального представительства которое может оказывать техподдержку.

Даже для редактирования диаграмм. Например мы - не смогли в своё время использовать Enterprise Architect потому что разработчики сидели в Австралии, а в РФ был только торговый дилер (сейчас возможно ситуация уже улчшилась, не проверял).

И вот угадайте почему ЦБ так делает? потому что менеджеры не хотят нести ответственность сверх необходимого. Потому что цена ошибки - очень велика. Если в ЦБ откажут майнфреймы и не сработает резервирование и за нормативные 4-6 часов они не вернут систему в строй - на следующий день страну будет лихорадить как при дефолте. ну или типа того)))

Это, конечно, крайний случай но между описанными полюсами, на той половине которая ближе к ЦБ - находится очень много крупных компаний с серьезными последствиями для компаний, если сработают риски связанные с отказом или сбоями в инструментах.

_________________
Ну вот как-то так... теперь "с кем заключать контракт" и какие условия...:

В cлучае с C++ - договор будет залючаться с производителем конкретного компилятора. Например - с локальным представительством майкрософта полагаю если вы пользуете их компиляторы. Кажется у них есть разные уровни подписки на VS ....

Подробнее могу рассказать про Java.
В случае Java - в РФ например есть несколько локальных сборщиков.
их предложения на поддержку - на скриншотах.

ГосJava (сертифицирована ФСТЕК): https://lab50.net/portfolio/%d0%b3%d0%be%d1%81java/

или Liberica JDK (ушел на сертификацию в ФСЕК осенью кажется): https://libericajdk.ru/pages/pricing/

_________
Ну и снова наконец про Rust. Пока команда поддержки и производитель будет один (как сейчас?), и пока они не смогут организовать стабильный процесс поддержки и будут ссориться со своими админами (как сейчас!) - путь для этого языка в большой интерпрайз - закрыт. имхо. А для языка с такими замашками как у раста - это, имхо, необходимо

Потому я и желаю им решить текущие проблемы и вынести из истории уроки.

>> А «тут» не передадут? И что же помешает?

не на том акцент делаете - читайте цитируемое предложение до конца.
"там" - инфа об уходе админов даже новостью бы не стала. это сделали бы тихо, постепенно и мирно.

им важно было 1) не доводить ситуацию до подобного "исхода", 2) договорится, и если не получится договорится - постепенно разводить конфликтующих, или заменять "проблемных" людей на их должностях.

а "коретим" с этими задачами не справилась, и получила как имиджевые потери, так и потенциально - нарушение процессов поддержки.

что в итоге? админов то заменят. но те кто не смог договоритсья со старыми админами они куда денутся? проблема имеет все шансы не решится только заменой админов. потому что см 2 предыдущих абзаца выше.

Мы про разное говорим. я говорю про проблемы стабильности , а вы как мне кажется, зачем то рассматриваете мои слова в контексте "сколько человек ушло".

Не важно сколько ушло, если с теми кто ушел оставшаяся команда смогла договориться и полюбовно расстаться, и это было тихо мирно и не повлияло на стабильность процессов, например связанных с поддержкой.

А сейчас, судя по всему, произошло совершенно иное. Не смогли договориться.

Потому я и говорю - "Могу только пожелать ребятам найти выход из этой ситуациии извлечь из истории уроки."

Что бы извлеченные уроки помогли им в будущем избежать подобных эксцессов. Пока же у них, похоже, орг.проблемы, с которыми надо еще справиться. Но может быть я ошибаюсь) "Будем посмотреть" как будет дальше.

давайте я повторю мысль :
""Бизнесу", требуются гарантии и поддержка разработчиком используемых "бизнесом" инструментов".

Это связано как с проблемами обновлений безопасности, так и с перекладыванием рисков, минимизацией затрат на развитие продукта и тд и тп. Бизнесу нужна компания, с которой они заключат договор и которая будет тянуть эти обязательства. Всегда и долго.

Понимаете?

Перспектива того, что кто-то там форкнет раст после того, как старая команда не смогла поддерживать его в силу внутренних тёрок - их не волнует.
Потому что форк - не спасет их от описанных выше проблем. Например потому, что контракт будет заключаться с одной командой, а вторая - даже если появится - не будет являться правоприемником этих контрактов.

Если мы видим, что компания не может договориться даже со своими же модерами на своем же форуме... будет сложно объяснить менеджерам компании в которой выбирают инстурментарий разработки - каким таким образом те люди из коанды создателей rust будут способны выполнять обязательства по поддержке и развитию, и зачем нашим менеджерам в компании использовать rust.


Я написал - "накренился".
У них, как я понимаю из доступной информации, какие-то серьезные внутренние проблемы в общении или взаимодействии, раз уж это вышло наружу и они не смогли решить эти проблемы тихо-мирно.

И если ребята не решат эти внутренние проблемы - а это чаще всего именно проблемы из области "менеджмента" - то, в перспективе, это приведет к проблемам с официальной тех.поддержкой. А это будет уже не просто "крен" - это уже направление на вылет на обочину истории.

А я же, кажется, когда то говорил об опасностях перевода проектов на новые, пусть и "вкуссные" языки, но создаваемые энтузиастами ?

Вы можете себе представить что "уход команды модераторов форума" будет "создавать проблему" для развития таких языков как Java, C# или С++?

вот и я не могу.
"там" просто передадут функции модерирования другому отделу, и не будут делать из этого события.

В общем... что имеем?
Очередной убийца C++ (или Java, или подставить по вкусу) - накренился в сторону вылета на обочину истории?

Неужели потому что языки претендующие на промышленные - помимо наличия стандартов и еще ряда элементов - надо развивать, вести и поддерживать вовсе не так, как это "делают энтузиасты"?

"Бизнесу", требующему гарантий и поддержки разработчиком используемых "бизнесом" инструментов - вовсе не интересны "внутрисемейные" терки создателей языка и модераторов форума, особенно если это приобретает характер влияющий на развитие и поддержку инструментов.

Могу только пожелать ребятам найти выход из этой ситуациии извлечь из истории уроки.


для того, что бы "прицепиться" к спутнику - надо будет по сути "пристыковаться" к нему, а стыковка, синхронизация орбит и маневры для этого дела - это не самые простые и быстрые вещи. вы потратите столько времени и топлива, что сами рады не будете.

Information

Rating
Does not participate
Registered
Activity