Pull to refresh
110
0
Victor Shcherb @vics001

Разработчик OsmAnd

Send message

Когда говорите, что учиться надо постоянно не только в программировании, но и в бухгалтерии вы путаете теплое с мягким. Программирование — инженерия, даже гораздо больше, чем любая другая. Программирование не существует отдельно от прикладной сферы, оно встречается и на заводах и в телефонах и в автомобилестроении и в обучении и в бухгалтерии, каждая предметная область имеет свои нюансы и имеет свой Аппаратно Программный Комплекс.


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

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


Говорить, что масштабирование и развитие технологий, которое требует гораздо больше усилий, чем их создание — что-то не принципиально новое — бред. Сейчас любой хороший студент напишет программы, которые были 50 лет назад.
P.S. кстати не понял почему в статье 25 лет назад, когда 50 лет назад уже было все известно и понятно к чему идет.

На героине торчки долго не держатся, а так наркотики могут и профессора покупат.

Ого как минусуют статью, а вопрос-то непростой.

Очень удобно, описывать сложности не более 3 категориями, остальное мозг уже не осилит.
Проект — Время, Деньги, Ресурсы (но мы то знаем...).

Прикольно, конечно, пример искусственый. Если где-то появляется портяночка if на instanceof, значит, кто-то где-то не освоил ООП — 99% случаев.

Я для себя выбор сделал. После 18 лет разработки на Java перешел на Kotlin — и очень этим доволен. Джаву хорошо знаю, люблю и уважаю, но вряд ли к ней когда нибудь вернусь. Для меня это пройденный этап.

Категорично, меньше не скажешь. То есть, лагерь разработчиков разделяется, одни не перейдут на Kotlin потому, что тонна legacy и никто не хочет, другие не перейдут на Java, потому что им не нравится. Ну я понимаю, когда люди переписывают с С++ на Java и наоборот… Но чисто по человечески это даже не .NET и JVM, это по сути одна кодовая база и, вряд ли, Kotlin ее когда-то всерьез изменит, зато 2 воинствующих лагеря "отцы-и-дети" ...

Я даже из статьи не понял, какая нагрузка создается на ЖД. Например, регулярное обновление OpenStreeetMap PSQL (1 TB), убивает "обычный" жесткий диск за 3 месяца, а тут кроме хранения, даже непонятно, что происходит. Как бы с этой "охотой на ведьм" не пострадали все высоконагруженные сервера.

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

Публичные соцсети типа Твитера и Хабра — добро :-) Надо 10 раз подумать, что сказать, а потом сказать.

Доказательство для чисел Фибонначчи из 1994г. http://www2.math.ou.edu/~dmccullough/teaching/miscellanea/miner.html. На основе такой технике можно доказать, что "число-89" будет существовать в любой системе исчислений

Тоже увлекался перестановками чисел 1/7 (0.1428571), 2/7 (...), 6/7. Долго думал, что это за магия, потом понял, что это вытекает из Малой теоремы Ферма, т.е. числа 10 и 7 взаимнопростые и (10)^6 =1 (mod 7), но для того, чтобы повторилась магия с зацикливанием надо, чтобы 10^X = 1 (mod P), X = P — 1 было минимальным числом. Примеры:


Для 10-чной системы, такой магией обладают числа: 7, 17, 19, 29, 47, 59, 61, 97.
Для 5-чной системы, такой магией обладают числа: 3, 7, 17, 23, 37, 43, 47, 53, 73, 83, 97


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


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


Что касается геометрических последовательностей, то это можно формализовать и доказать, вроде как паттерн в них виден.


Что касается чисел Фибоначчи, то тут надо копать в реккурентные формулы, это как раз неочевидно, почему именно 89 и 109.


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

Наверное в групповых нет End-To-End шифрования
При экономной организации файлового хранилища экономия в 5-10 раз, если закупать 10-15 TB HDD.
С `:-`, ',' — на Пролог похож. Но зачем-то тогда изобретать новый язык…
Статья написана про опыт работе на галере, но подается как общемировая проблема. Компании не важно сколько вы ночей просидите или не просидите, чтобы сделать бухгалтерский отчет, важно, чтобы он был сделан к 15 числу и так каждый месяц! Все печеньки и плюшки, прежде всего, выбивают уже работающие сотрудники, чтобы работать было веселее.

Можно рассуждать, о чем угодно, но если вы работаете на галере, то работодатель получает деньги за Ваши Часы на галере, чем больше вы на галере, тем лучше. И все проблемы со сроками и качеством, на галере всегда закрываются overtime. Но не надо галерный опыт распространять на все компании… В конце концов, поэтому на стройках — галерах больше платят…
Вопросы-ответы M&A могут быть очень сложными, но они точно должны изучать уже написанный код-архитектуру, а не то, что CTO на коленке настрочит.
Если у вас нет IPv4 адреса (только IPv6), то к серверу, который не поддерживает IPv6 вы не подключитесь.
Кажется ускорить переход на IPv6 через бизнес — не сработало. IP-адрес сервера может стоить «гораздо дороже», чем IP-адрес клиента, просто потому, что 1 сервер обслуживает очень много клиентов. С точки зрения бизнеса, необходимо иметь настроенный IPv4, чтобы обслуживать всех клиентов.

Тут скорее надо ждать, когда некоторых «клиентов» принудительно переведут на IPv6 и они уже потребуют от бизнеса, чтобы все работало и на IPv6. Больно, но а как еще…
Суть проста — бей или беги, ИИ это и не надо.

Information

Rating
Does not participate
Location
Антильские о-ва
Date of birth
Registered
Activity