полезные конечно короткие примеры(но далеко не все), но есть замечания (я видел что это перевод):
"Архитектуру баз данных можно разделить на следующие категории:"? (посмотрел оригинал "The design of databases can be separated into these categories:", суть в том что база данных соответствует одной из нормальных форм(это не перевод), кстати список нормальных форм не полный)
Зачем мне выкладывать доработанную программу в опенсорс, когда я могу просто ей пользоваться у себя в конторе?
поддержка обратной совместимости.
С выходом новой версии проги, надо будет тащить патч в вашу версию софтины и пересобирать ее для вас, или не сможете пользоваться новой версией программы.
Тут вариант отправки патча в апстрим и выигрывает, платить каждый раз программисту может оказаться дороже, чем один раз отправить в апстрим и уже новая версия сразу будет с вашей фитчей.
ну я не совсем согласен в изначальной статье на тему имутабельный список может содержать мутабельные объекты, тогда зачем нужен такой "имутабельный" список? вопрос конечно же философский.
Мне привычней классическая терминалогия, мутабельных или имутабельных объектов.
к сожалению это не совсем имутабельный объект получится.
Дело в том что объект имутабельный если он не меняет свое состояние, элементы списка это тоже часть состояния и они должны быть неизменны то есть тоже имутабельны, если на это забить то получится следующее
# в виде псевдо кода
1. создадим текущую дату в переменную current
2. поместим current в ImmutableList
3. достаним первый элемент списка и выведем дату
4. обратимся к переменной current и изменим дату
5. повторим пункт 3 и получим другой результат
И мы получили что наш "имутабельный" объект вызывая один и тот же метод с одинаковыми аргументами возвращает разное, чего быть не должно.
Гибкие методологии разве требуют избавиться от планирования?
я этого не говорил.
Помните в самом начале написал мысль о том что "9 женщин не смогут родить ребенка за 1 месяц" если переводить мысль более подробно, то вы пытаетесь большое число сотрудников (ролей) задействовать в разработке ОДНОЙ фичи и пытаетесь в рамках этой фитчи ее оптимизировать чтобы стартовать скажем так подзадачи параллельно. При этом большое число ролей работающих над одной фитчей должны между собой комуницировать и шарить знания, что тоже как бы затратно.
Вместо этого проще брать больше фитч в работу и меньшее число сотрудников оставлять в работе над фичей (у вас там по фронту только 6 частей идет паралельно, а значит это разные сотрудники или он будет выполнять эти задачи последовательно).
За счет меньшей команды у них будет меньше комуникаций между ролями и больше времени на работу, пусть они там в 2 или 3 сделают фитчу чуть позже, чем как вы указали в 6 или больше, хотя разница во времени будет небольшой, при этом другие 2 — 3 человека смогут взять и делать другую фитчу для бизнеса паралельно и к концу спринта (плюс например неделя вы получите уже две фичи вместо одной, неделя это цифра с потолка).
Поэтому я думаю надо оптимизировать не выполнения одной задачи большим числом людей(ролей), а паралельно запускать большое число задач (в соответствие с доступными ресурсами и доступными задачами для запуска паралельно).
Я лишь прочитал и высказал что мне кажется может не сработать, при этом я согласен что в начале фронт потом бэк, просто я думаю некоторые вещи иногда нет нужды запускать паралельно, полученный профит по срокам может быть перекрыт от проблем с комуникациями и переделками, тут все надо выбирать индивидуально (от команды).
так вы пытаетесь выдавить скорость из разработки, паралеля все что можно, но при этом все равно привязаны к сроку спринта в 7 или 14 или сколько там у вас он идет и фидбэк будет собран не раньше его окончания, а если фидбэк будет собран раньше то зачем спринты? и релизы вне спринта.
я вижу разбиение задач и их планирование у вас как в waterfall, но при этом аргументируете это гибкой разработкой и скоростью, хотя я опять же могу ошибаться, главное чтобы вам нравилось.
я бы предположил что вам может подойти канбан, по крайне мере по тому как вы работаете с гитом, как раз тут спринты не нужны, как освободились люди берут новую таску, по мере готовности собирается фидбэк, релиз по таскам отдельно (не привязано ко всему спринту) и в произвольное время.
вы увидели что ветка import отстает от master
в master есть что то очень важное
ветка import прошла qa и что касается фичи все ок, но есть конфликты с мастером и надо убедится что не будет регресов после внивания в мастер, так получилось что общие компоненты правили.
теперь когда изменения из master будут вливаться возник конфликт, как определить кому их разрешать? у вас в ветке знания размазаны по различным ролям (куча людей) и та ветка что влита была тоже знания размазаны по куче людей, как убедится что разрешение конфлитка ничего не сломало?
e2e на самом деле у нас и пишутся в параллели, но идет это дело долго и поэтому все равно они будут готовы позже готовности прототипа UI.
получается e2e остается для того чтобы обнаруживать регресс?
Не понятно каких конкретно вы имеете в виду разработчиков
Вы начали сприпт, у вас большая команда и импорт данных это одна из задач, есть и другие которые будут делаться другими людьми (или в том числе и этими же), так получилось что другие задачи сделали раньше чем импорт, разработчикам работающим над импортом придется учитывать и влитые эти задачи и при merge или rebase могут возникнуть конфликты, далее разработчики что не влили в ветку импорта, придется делать тоже самое (мержить или ребейзить свои правки) на актуальные данные.
Если конфликтов при такой ситуации не может возникнуть, то почему бы разработчикам изначально в ветке импорта не работать или как им удобно, а не так как:
Но когда разные части делаются не в синхроне и из мастера автоматом изменения доставляются на стейдж, мы получим таким путем сбой доставки в прод.
Так у вас же спринты, вы в начале спринта делаете ветку спринт№123 и она становится dev веткой, а когда спринт заканчивается вся ветка вливается в мастер и релиз (ну так по обычному git flow).
Если вы делаете отдельные фитч ветки вроде import и тд и потом по мере готовности вливаете в master и делаете сразу релиз, то у вас получается github flow и зачем вам использовать спринты? делайте релизы по мере готовности без привязки к спринту.
Я просто участвовал в подобной реализации такой фичи и в начале тоже планировали одно, а надо было совсем другое, чем раньше показывается промежуточный результат, тем быстрее понятно в ту ли сторону вы двигаетесь точно также и про процесс разработки, чем он проще и легче, тем больше времени на разработку, это лишь мое имхо возможно я ошибаюсь.
если меняются ожидания то правят и E2E, после правки E2E проект может перестать им соответствовать.
Вместо спеке конкретный набор критериев(тестов) которым должна соответствовать система, если система не соответствует ожиданиям значит мало критериев и надо уточнять.
Как контролировать отсутствие ошибок в тестах?
Если система соответствует тестам, но не подходит тем кто заказывал ее то значит ошибки где то в тестах, меняются тесты и следом система.
прочитал статью, во первых хотелось бы сказать спасибо за труд, но есть некоторые вещи которые мне кажутся не очень логичными.
Вы начинаете показывать альфа версию, когда уже готов бэк, если предположения фронта были не правильные или требуются переделки, то работа по бэку была в стол, почему бы не показывать фронт когда он на тестовых данных? и собирая фидбэк вносить корректировки.
У вас есть спецификация (я не о формате ответов от апи) по фронту и e2e тесты, смысл держать спеку, ведь e2e тесты покажут насколько фронт соответствует тому что ожидается, я бы предложил делать e2e тесты раньше фиксируя ожидаемое поведение и фиксируя спеку, прошел e2e соответствуешь спеке.
Ну и самое забавное, вы предлагаете разбивать задачи на большое число веток (ничего против веток не имею и git с ними справится) но ваш профит в том что придется решать меньше конфликтов, но теперь представьте пока вы фичу делаете в мастер влили другую фитчу(другая команда) и возникли конфликты (это нормально), вы делаете rebase или merge для import ветки разрешаете их, потом другие разработчики вливают к себе import ветку и тд, а теперь другая ситуация, вы собрали ветку import влили все ветки фронта и бэка и возникли конфликты при вливание вашей мега большой ветки в мастер (или дев) и теперь все участники должны быть чтобы по решать конфликты (причем двух больших веток что вливали).
Я бы предложил отдельные ветки разработчиков с частями фитчи import, сразу вливать в мастер (или дев, она же не релизит это).
Прочитал про количество ролей что ожидается использовать: фронтовики, бэкендеры, редактор спецификации, мейнтенеры ветки фичи, уверены что последние 2 нужны? может я еще кого то забыл.
Есть еще нюансы которые лично у меня вызывают вопросы, но хотелось бы иногда сказать что далеко не все процессы можно запускать параллельно и то что не всегда процесс выполняемый параллельно быстрее последовательного выполнения.
Мои любимый анегдот в тему паралельности, менеджер думает что если одна девушка рожает ребенка за девять месяцев, то девять девушек сделают ребенка за один месяц.
большинству не надо 100мбит, многим достаточно 2мбит будет, но вот если у всех операторов написано что скорость до х мбит, а какая реальная скорость хз никто не знает, вот если было бы написано что скорость о У до Х мбит и лимит на день Z мбит и после скорость X2 становится было бы честней не находите с точки зрения потребителя.
про кривое оборудование которое не может предоставить скорость я сразу написал что все эти истории не стоит упоминать я прекрасно понимаю что есть такие индивидумы, речь о том чтобы в тарифе писали правду
подумайте какие проблемы с 2g/3g/4g и как показания зависят от "шума" и загруженности станции, тут вообще очень сложно что то гарантировать.
подумайте про историю когда инструкции для сотрудников вышли в инет где включали шейпинг для людей пользующихся интернетом (там при достижение определенных лимитов ограничивалась скорость сильнее чем прописано в тарифе), я прекрасно понимаю зачем (оборудование не справляется и чтобы другим хоть что то оставалось, но это опять же оверселинг), но пусть будут добры указать в тарифе что скорость такая то но при привышение лимита она будет такая, но никто это не указывал и не разглашал
поэтому посчитать что цифру, у компании N мбит внешний гарантированный канал, у компании M юзеров с максимальным ограничением Х2, тогда худщая ситуация (с точки зрения математики) Х1 = N / (M * X2) и вот в тарифе указать что скорость от X1 до X2
и вот потребитель смотря на Х1 будет примерно понимать у кого какой оверселинг и чтобы ее повышать провайдеры будут занижать Х2, я понимаю что в реальности она не гарантируется и может быть ниже Х1 и что обычно скорость намного выше Х1
но сейчас цифра Х1 неизвестна никому и нигде не публикуется.
оценить скорость по воздуху это отдельная история со своими ограничениями там чуть по сложней считать но тоже эта цифра хоть что то покажет и позволит потребителю выбрать для себя лучшие услуги из доступных.
а сейчас каждый провайдер может писать что угодно, но внешний канал он вообще рандомный, недостаток ipv4 плевать обновляться до ipv6 не будет, ведь клиентское оборудование dir320 и тд, просто кто то вместо того чтобы вкладывать деньги в развитие инфраструктуры вкладывает слишком много в свой карман (я понимаю что комерческие компании создаются для извлечение прибыли, но не стоит мочить корову дающую молоко имхо).
представляю, но тут речь не об отсутствие оверселинга в целом, а о том что маркетологи слишком много себе позволяют когда хотят заманить клиента и поэтому они должны отвечать за то что пишут, тут речь о том что указывая верхний предел не плохо было бы видеть и нижний предел, пусть этот нижний предел тоже измереяется провайдером и берется худшее показание за прошлый месяц или еще какое значение, но имеющее что то общее с реальностью, а не маркетинговые обещания.
ну например указать скорость до msk-ix или любой другой (за пределами этого провайдера).
вы точно также перекупая трафик получите тарифы которые вам также как потребителю должны гарантироваться.
Поэтому если оверселите канал то вина ваша, а если внешний канал не предоставил обещанной скорости то вас как потребителя также обманули и виноват он,
тогда вы получите актуальные данные по внешним каналам, с учетом нагрузки сможете составить свои тарифы и все счастливы, но это мое имхо.
Ситуации типо клиентское оборудование не тянет скорость отметаем.
Потому что маркетологи что угодно пишут лижбы заполучить клиента, а потом начинается у нас вышки нагружены ( а на самом деле внутренние ограничения) не используйте торенты и тд, провайдер предоставляется услуга внешней связи, а не связи внутри провайдера на втором модели ip.
С этим мнением можно соглашаться, а можно нет, но если бы провайдер писал не лучший показатель скорости, а самый худший было честней, кмк.
Для каждого сервиса генерируем email постоянный на специальных сервисах который будет пересылать письма к вам на ящик в шаге 1.
Если мы сообщаем свой настоящий ящик другу в реале, то вносим его ящик в white list
Все письма не от сервиса и не из whitelist в спам.
Дополнительный профит, если какой то сайт продал базу адресов или ее слили, вы можете в сервисе(где генерировали email) просто удалить временный ящик и весь спам прекратиться (отпишитесь от получения писем с этого сайта), можно сгенерировать новый email и прописать его в сайте и уведомления к вам пойдут через него, а тот ящик что оказался у спамеров будет уходить в /dev/null
Сервисы для шага 2 их довольно много в гугле и они бесплатны.
Я писал, что в режиме большого приближения изображение целиком сложно воспринять.
Понятие приближения зависит от изображения и от того что вы хотите увидеть, но обратите внимание вы сами начали говорить о
не имеет смысл резать на отдельные функции что-то цельное, например алгоритмы
Вы сами начали говорить о приватных методах, вместо того чтобы смотреть на картину, вы начали упоминать о пикселях из которых она состоит (приватных методов).
И я вам показал пример алгоритма где имеет смысл делить на отдельные методы, это rsa.
И да, не вижу ни одной причины из обсуждения в этой ветке, почему кто-то должен всё объединять в одну функцию
Вот я это уже цитировал выше повторю "не имеет смысл резать на отдельные функции что-то цельное, например алгоритмы"
теперь по поводу работы с большими числами это тоже алгоритмы, а значит исходя из ваших же слов не имеет смысла резать на отдельные функции, да алгоритм сложения больших чисел один, но есть куча алгоритмов умножения например.
Сложность зависит только от кол-ва функций? complexity(functionCount) или есть еще другие параметры ?
Например, в случае с алгоритмом Флойда, знающему его человеку ориентироваться будет проще, чем в длинном.
каким образом знание или незнание алгоритма зависит от его длинны? если я перепишу алгоритм флойда в одну строку вам будет проще в нем ориентироваться и он станет вам более знакомым?
кто вам сказал что псевдо код выложенный на сайте вики это единственная реализация?
вы слышали о различных парадигмах программирования и что в рамках этих парадигм также может применяться алгоритмы и иметь разные реализации которые визуально будут не очень похожи друг на друга, но при этом возвращать одинаковые результаты.
попробуйте реализовать алгоритм флойда в рамках фп и посмотрите понадобится ли вам вспомогательные функции (в том числе и анонимные).
полезные конечно короткие примеры(но далеко не все), но есть замечания (я видел что это перевод):
"Архитектуру баз данных можно разделить на следующие категории:"? (посмотрел оригинал "The design of databases can be separated into these categories:", суть в том что база данных соответствует одной из нормальных форм(это не перевод), кстати список нормальных форм не полный)
по поводу коде стайла для именования https://www.sqlstyle.guide/ru/ хороший пример с объяснениями.
поддержка обратной совместимости.
С выходом новой версии проги, надо будет тащить патч в вашу версию софтины и пересобирать ее для вас, или не сможете пользоваться новой версией программы.
Тут вариант отправки патча в апстрим и выигрывает, платить каждый раз программисту может оказаться дороже, чем один раз отправить в апстрим и уже новая версия сразу будет с вашей фитчей.
тогда ему имя ImmutableList не очень подходит, скорей это UnmodifiedList, по моему скромному мнению.
ну я не совсем согласен в изначальной статье на тему имутабельный список может содержать мутабельные объекты, тогда зачем нужен такой "имутабельный" список? вопрос конечно же философский.
Мне привычней классическая терминалогия, мутабельных или имутабельных объектов.
к сожалению это не совсем имутабельный объект получится.
Дело в том что объект имутабельный если он не меняет свое состояние, элементы списка это тоже часть состояния и они должны быть неизменны то есть тоже имутабельны, если на это забить то получится следующее
И мы получили что наш "имутабельный" объект вызывая один и тот же метод с одинаковыми аргументами возвращает разное, чего быть не должно.
Это еще не считая шаманств с рефлекшен.
я этого не говорил.
Помните в самом начале написал мысль о том что "9 женщин не смогут родить ребенка за 1 месяц" если переводить мысль более подробно, то вы пытаетесь большое число сотрудников (ролей) задействовать в разработке ОДНОЙ фичи и пытаетесь в рамках этой фитчи ее оптимизировать чтобы стартовать скажем так подзадачи параллельно. При этом большое число ролей работающих над одной фитчей должны между собой комуницировать и шарить знания, что тоже как бы затратно.
Вместо этого проще брать больше фитч в работу и меньшее число сотрудников оставлять в работе над фичей (у вас там по фронту только 6 частей идет паралельно, а значит это разные сотрудники или он будет выполнять эти задачи последовательно).
За счет меньшей команды у них будет меньше комуникаций между ролями и больше времени на работу, пусть они там в 2 или 3 сделают фитчу чуть позже, чем как вы указали в 6 или больше, хотя разница во времени будет небольшой, при этом другие 2 — 3 человека смогут взять и делать другую фитчу для бизнеса паралельно и к концу спринта (плюс например неделя вы получите уже две фичи вместо одной, неделя это цифра с потолка).
Поэтому я думаю надо оптимизировать не выполнения одной задачи большим числом людей(ролей), а паралельно запускать большое число задач (в соответствие с доступными ресурсами и доступными задачами для запуска паралельно).
Я лишь прочитал и высказал что мне кажется может не сработать, при этом я согласен что в начале фронт потом бэк, просто я думаю некоторые вещи иногда нет нужды запускать паралельно, полученный профит по срокам может быть перекрыт от проблем с комуникациями и переделками, тут все надо выбирать индивидуально (от команды).
так вы пытаетесь выдавить скорость из разработки, паралеля все что можно, но при этом все равно привязаны к сроку спринта в 7 или 14 или сколько там у вас он идет и фидбэк будет собран не раньше его окончания, а если фидбэк будет собран раньше то зачем спринты? и релизы вне спринта.
я вижу разбиение задач и их планирование у вас как в waterfall, но при этом аргументируете это гибкой разработкой и скоростью, хотя я опять же могу ошибаться, главное чтобы вам нравилось.
я бы предположил что вам может подойти канбан, по крайне мере по тому как вы работаете с гитом, как раз тут спринты не нужны, как освободились люди берут новую таску, по мере готовности собирается фидбэк, релиз по таскам отдельно (не привязано ко всему спринту) и в произвольное время.
вы увидели что ветка import отстает от master
в master есть что то очень важное
ветка import прошла qa и что касается фичи все ок, но есть конфликты с мастером и надо убедится что не будет регресов после внивания в мастер, так получилось что общие компоненты правили.
теперь когда изменения из master будут вливаться возник конфликт, как определить кому их разрешать? у вас в ветке знания размазаны по различным ролям (куча людей) и та ветка что влита была тоже знания размазаны по куче людей, как убедится что разрешение конфлитка ничего не сломало?
получается e2e остается для того чтобы обнаруживать регресс?
Вы начали сприпт, у вас большая команда и импорт данных это одна из задач, есть и другие которые будут делаться другими людьми (или в том числе и этими же), так получилось что другие задачи сделали раньше чем импорт, разработчикам работающим над импортом придется учитывать и влитые эти задачи и при merge или rebase могут возникнуть конфликты, далее разработчики что не влили в ветку импорта, придется делать тоже самое (мержить или ребейзить свои правки) на актуальные данные.
Если конфликтов при такой ситуации не может возникнуть, то почему бы разработчикам изначально в ветке импорта не работать или как им удобно, а не так как:
Так у вас же спринты, вы в начале спринта делаете ветку спринт№123 и она становится dev веткой, а когда спринт заканчивается вся ветка вливается в мастер и релиз (ну так по обычному git flow).
Если вы делаете отдельные фитч ветки вроде import и тд и потом по мере готовности вливаете в master и делаете сразу релиз, то у вас получается github flow и зачем вам использовать спринты? делайте релизы по мере готовности без привязки к спринту.
Я просто участвовал в подобной реализации такой фичи и в начале тоже планировали одно, а надо было совсем другое, чем раньше показывается промежуточный результат, тем быстрее понятно в ту ли сторону вы двигаетесь точно также и про процесс разработки, чем он проще и легче, тем больше времени на разработку, это лишь мое имхо возможно я ошибаюсь.
E2E отражают ожидания(требования).
если меняются ожидания то правят и E2E, после правки E2E проект может перестать им соответствовать.
Вместо спеке конкретный набор критериев(тестов) которым должна соответствовать система, если система не соответствует ожиданиям значит мало критериев и надо уточнять.
Если система соответствует тестам, но не подходит тем кто заказывал ее то значит ошибки где то в тестах, меняются тесты и следом система.
Философский вопрос, хоть откуда если коротко.
прочитал статью, во первых хотелось бы сказать спасибо за труд, но есть некоторые вещи которые мне кажутся не очень логичными.
Я бы предложил отдельные ветки разработчиков с частями фитчи import, сразу вливать в мастер (или дев, она же не релизит это).
Есть еще нюансы которые лично у меня вызывают вопросы, но хотелось бы иногда сказать что далеко не все процессы можно запускать параллельно и то что не всегда процесс выполняемый параллельно быстрее последовательного выполнения.
Мои любимый анегдот в тему паралельности, менеджер думает что если одна девушка рожает ребенка за девять месяцев, то девять девушек сделают ребенка за один месяц.
а вариант сложить свои "скрипты" в библиотеку и подключать к проекту в виде библиотеки? с помощью пакетного менеджера языка.
поэтому посчитать что цифру, у компании N мбит внешний гарантированный канал, у компании M юзеров с максимальным ограничением Х2, тогда худщая ситуация (с точки зрения математики) Х1 = N / (M * X2) и вот в тарифе указать что скорость от X1 до X2
и вот потребитель смотря на Х1 будет примерно понимать у кого какой оверселинг и чтобы ее повышать провайдеры будут занижать Х2, я понимаю что в реальности она не гарантируется и может быть ниже Х1 и что обычно скорость намного выше Х1
но сейчас цифра Х1 неизвестна никому и нигде не публикуется.
оценить скорость по воздуху это отдельная история со своими ограничениями там чуть по сложней считать но тоже эта цифра хоть что то покажет и позволит потребителю выбрать для себя лучшие услуги из доступных.
а сейчас каждый провайдер может писать что угодно, но внешний канал он вообще рандомный, недостаток ipv4 плевать обновляться до ipv6 не будет, ведь клиентское оборудование dir320 и тд, просто кто то вместо того чтобы вкладывать деньги в развитие инфраструктуры вкладывает слишком много в свой карман (я понимаю что комерческие компании создаются для извлечение прибыли, но не стоит мочить корову дающую молоко имхо).
представляю, но тут речь не об отсутствие оверселинга в целом, а о том что маркетологи слишком много себе позволяют когда хотят заманить клиента и поэтому они должны отвечать за то что пишут, тут речь о том что указывая верхний предел не плохо было бы видеть и нижний предел, пусть этот нижний предел тоже измереяется провайдером и берется худшее показание за прошлый месяц или еще какое значение, но имеющее что то общее с реальностью, а не маркетинговые обещания.
ну например указать скорость до msk-ix или любой другой (за пределами этого провайдера).
вы точно также перекупая трафик получите тарифы которые вам также как потребителю должны гарантироваться.
Поэтому если оверселите канал то вина ваша, а если внешний канал не предоставил обещанной скорости то вас как потребителя также обманули и виноват он,
тогда вы получите актуальные данные по внешним каналам, с учетом нагрузки сможете составить свои тарифы и все счастливы, но это мое имхо.
Ситуации типо клиентское оборудование не тянет скорость отметаем.
Потому что маркетологи что угодно пишут лижбы заполучить клиента, а потом начинается у нас вышки нагружены ( а на самом деле внутренние ограничения) не используйте торенты и тд, провайдер предоставляется услуга внешней связи, а не связи внутри провайдера на втором модели ip.
С этим мнением можно соглашаться, а можно нет, но если бы провайдер писал не лучший показатель скорости, а самый худший было честней, кмк.
Есть хороший способ как побороть для себя спам.
Дополнительный профит, если какой то сайт продал базу адресов или ее слили, вы можете в сервисе(где генерировали email) просто удалить временный ящик и весь спам прекратиться (отпишитесь от получения писем с этого сайта), можно сгенерировать новый email и прописать его в сайте и уведомления к вам пойдут через него, а тот ящик что оказался у спамеров будет уходить в /dev/null
Сервисы для шага 2 их довольно много в гугле и они бесплатны.
вы переизобрели pgp.
очень давно можно было использовать обычный email и дополнительные тулзы http://lmgtfy.com/?q=email+pgp
на выходе чтобы прочитать письмо надо знать приватный ключ, на серверах лежит зашифрованное письмо.
Write once, run anywhere — пытаюсь применить это к java 9 со сроком поддержки в 7 месяцев
Понятие приближения зависит от изображения и от того что вы хотите увидеть, но обратите внимание вы сами начали говорить о
Вы сами начали говорить о приватных методах, вместо того чтобы смотреть на картину, вы начали упоминать о пикселях из которых она состоит (приватных методов).
И я вам показал пример алгоритма где имеет смысл делить на отдельные методы, это rsa.
Вот я это уже цитировал выше повторю "не имеет смысл резать на отдельные функции что-то цельное, например алгоритмы"
теперь по поводу работы с большими числами это тоже алгоритмы, а значит исходя из ваших же слов не имеет смысла резать на отдельные функции, да алгоритм сложения больших чисел один, но есть куча алгоритмов умножения например.
Сложность зависит только от кол-ва функций? complexity(functionCount) или есть еще другие параметры ?
каким образом знание или незнание алгоритма зависит от его длинны? если я перепишу алгоритм флойда в одну строку вам будет проще в нем ориентироваться и он станет вам более знакомым?
кто вам сказал что псевдо код выложенный на сайте вики это единственная реализация?
вы слышали о различных парадигмах программирования и что в рамках этих парадигм также может применяться алгоритмы и иметь разные реализации которые визуально будут не очень похожи друг на друга, но при этом возвращать одинаковые результаты.
попробуйте реализовать алгоритм флойда в рамках фп и посмотрите понадобится ли вам вспомогательные функции (в том числе и анонимные).