Это кажется странным пока не вспоминаешь про семидневную неделю, 60-минутный час, 360-градусный круг и многие другие, пускай и более редко используемые единицы
Ну это же художественное произведение, где имеет место гипербола и доведение до абсурда. Естественно, что в реальности вменяемые разработчики не стали бы даже пробовать играть в эти игры, а после первого же идиотского требования спокойно нашли в течение пары недель позицию не хуже, а компания ещё долго бы не могла никого (такого же уровня) нанять, т.к. была бы прославлена на соответствующих ресурсах. И на хабре подобные реальные истории проскакивали не раз
Еще полезны LION'ы — (LinkedIn Open Networker) — это люди которые принимают в друзья всех подряд. У них в контактах как правило много рекрутеров, которые таким образом смогут найти и связаться с вами.
Ни то ни то не верно на 100%
1. Кросс-платформенность ограничена определенным количеством известных платформ. У того же reqwest, на сколько я помню, нет биндингов на ios или на тот же redox (операционная система, разрабатываемая на расте). Следовательно, работать программа не будет.
2. На линукс reqwest требует OpenSSL, а на виндовс любой бинарник, собраный с msvc-тулчейном (рекомендуемым по умолчанию), требует установленный ms c++ runtime той же версии.
P.S. Это не критика, а уточнение, полезное для тех, у кого раст — первый системный язык программирования. В отличии от java/python/c#/etc системный язык требует куда более тщательной проверки зависимостей
Ну у C# совсем другая среда исполнения. И у С++ тоже. Кроме того, даже у JVM-based языков может быть выделенный в отдельный файл рантайм. И наоборот, набор просто утилит, который по-умолчанию включен в сборку, даже если не используется. Поэтому просто по размеру сложенных в директорию файлов и их размерам сложно дать оценку «нагенеренной прослойки», а размер «полезной» части бинарника, в свою очередь напрямую зависит от того насколько богат рантайм.
Можно относительно честно сравнить размеры компилируя всё статически (и даже здесь будет чувствоваться влияние разных ОС и архитектуры системы под которую собираем). Но даже сравнивая эти цифры, довольно сложно сделать какие-то выводы наверняка.
Очевидно, что поддержка редактирования документов в офисе 2003 не является критичным кейсом для среднестатистического пользователя в Германии в ноябре 2017 года. Поэтому эту, несомненно значимую группу пользователей решили просто игнорировать, преступно нарушив их права. Не удивлюсь, если у них и файлы на дискетах 5.25’’ не принимают
Забавно, в том же самом 1997 я был в 8 классе и в Волгоградской детской библиотеке была ровно одна книга в читальном зале, в которой объяснялось про массивы. И я тоже довольно надолго завис на них.
В контексте микросервисов это слишком общий вопрос. Тут нужно уточнять конкретный кейс.
Если для хранения контекста не подходит само тело запроса/ответа (самый удобный вариант), можно использовать внешнюю бд (в зависимости от задачи она может быть распределенной и со строгой консистентностью.) Ещё есть вариант с месседж брокером (очередью сообщений), если операция для вас слишком долгая, чтобы держать коннект. Хотя это уже инфраструктурные детали.
Для отработки отказа нужна процедура отработки отказа, которая пройдёт по всему пайплайну (по всему дереву вызовов скорее) и откатит изменения определенной транзакции, исходя из лога совершенных транзакций.
Это совсем нелегкая задача для реализации, поэтому в микросервисной архитектуре стремятся её избегать разными способами, (например, ограничивая количество персистирующих микросервисов в каждой цепочке вызовов до одного)
И всё-таки высокопроизводительные системы довольно дороги. Кроме того, возникает немаловажный вопрос удобства и скорости реакции — помимо принятия решения, трейдер должен сообразить, за какую клавиатуру/мышку хвататься, чтобы провести операцию. Уверен, перекладывание рук трейдера между консолями занимает гораздо больше времени, чем то критичное латенси тонкого клиента, о котором шла речь в статье.
Разве не лучше поставить одну мощную многомониторную станцию с едиными органами управления, а проблемы с несколькими сетями решить централизованно классическими корпоративными способами — фаерволлом и разграничением доступа?
Исправь просто программиста на синьор-программиста (в офисе) и зарплата $10k gross вполне попадет в свою вилку (по-крайней мере для моего региона).
Из них обязательные траты примерно такие:
3500 — это налоги. Около 1000 — медстраховка для всей семьи. И это еще дешево. Обамакер с нашим доходом работает против нас — платим считай за себя и за того (бедного) парня.
~2000 — съем жилья с хорошими школами, свет, вода, интернет и мобильники с рассрочкой. Ипотека дороже.
1000 — две машины в лиз и страховка на них. Да, можно взять used в кредит, но выигрыш баксов в 200/mo весьма сомнителен и может запросто нивелироваться необходимостью ремонта и вынужденного простоя на работе (с этим уровнем дохода дешевле держать новую машину).
Еще желательно контрибьютить что-то в пенсию. Ну пусть $500.
Остается ~2000 на еду, одежду, детские и взрослые активити, а также на возможные дидактаблы по страховым случаям.
В сухом остатке получаем, что до 2014 года смысла переезжать из москвы только ради денег не было. Сейчас — есть.
В статье умалчивается тот факт, что программист на джаве с таким же опытом (или просто хороший синьор с правильным скиллсетом) получит в нью-йорке 120-150 в час в финансовой сфере.
Тот факт, что существует некое альтернативно-одаренное, внешне похожее на файловое апи, позволяющего с дикими ограничениями получить доступ к некоторым объектам операционной системы — так это ведь вообще не аргумент. Само его существование (иначе как для получения некоей общей справочной информации о состоянии ОС) — большой архитектурный просчет — вне зависимости от операционной системы, качества реализации и «жирности». Просто обобщать сущности не имеющие друг с другом ничего общего — плохая практика…
Если один процесс пытается получить информацию о другом (о том что он запущен), то это в любом случе IPC просто по-определению этого термина. Блокируя файл, ты все-равно делаешь IPC, но не напрямую, а через посредника. Критерии «жирности», кстати, раз уж ты их упомянул, тоже дело довольно второстепенное. Хотя я не могу взять в толк, почему писать в шареную память «жирно», а на диск — нормально?
ЗЫ: Ну и по-поводу существования FHS — это тоже не аргумент. Еще в системе TCP-стек должен быть. И что теперь — давай сокет открывать по этому поводу? как альтернативу lock-файлу?:
Принципиальная проблема не в том, что ваше решение не будет работать, а в том, что для решения используются спроектированные для иных целей вещи.
В случае windows куда более логично использовать мьютекс, который по определению специально для таких целей и создан, а не городить костыли, считая любой объект в системе гвоздём файлом.
А linux, на сколько я знаю, для решения таких задач предполагает использование семафора на разделяемой памяти. Тоже не требующего такой сильной зависимости как разрешение на запись на диск.
Правильно — это не использовать вещи не по назначению и не делать ненужных зависимостей. Я очень сомневаюсь, что цель файловой системы — это отслеживание запусков второго инстанса приложения.
И, между прочим, это каноничный пример того, как опыт создания скриптов из костылей, столь характерный для администрирования маленьких предприятий, в этом конкретном случае пошел разработчику во вред.
Ваше «решение» невозможно запустить на бездисковых системах и на системах с read-only носителями. Также потребуется решить проблемы с правами доступа приложения/пользователя на запись. Относительный путь или абсолютный — еще одна проблема. Как и API — не всякий поддерживает UNC-пути, например.
1. Кросс-платформенность ограничена определенным количеством известных платформ. У того же reqwest, на сколько я помню, нет биндингов на ios или на тот же redox (операционная система, разрабатываемая на расте). Следовательно, работать программа не будет.
2. На линукс reqwest требует OpenSSL, а на виндовс любой бинарник, собраный с msvc-тулчейном (рекомендуемым по умолчанию), требует установленный ms c++ runtime той же версии.
P.S. Это не критика, а уточнение, полезное для тех, у кого раст — первый системный язык программирования. В отличии от java/python/c#/etc системный язык требует куда более тщательной проверки зависимостей
Можно относительно честно сравнить размеры компилируя всё статически (и даже здесь будет чувствоваться влияние разных ОС и архитектуры системы под которую собираем). Но даже сравнивая эти цифры, довольно сложно сделать какие-то выводы наверняка.
Если брать пакет на семью, например, то выйдет лучше и дешевле
Если для хранения контекста не подходит само тело запроса/ответа (самый удобный вариант), можно использовать внешнюю бд (в зависимости от задачи она может быть распределенной и со строгой консистентностью.) Ещё есть вариант с месседж брокером (очередью сообщений), если операция для вас слишком долгая, чтобы держать коннект. Хотя это уже инфраструктурные детали.
Для отработки отказа нужна процедура отработки отказа, которая пройдёт по всему пайплайну (по всему дереву вызовов скорее) и откатит изменения определенной транзакции, исходя из лога совершенных транзакций.
Это совсем нелегкая задача для реализации, поэтому в микросервисной архитектуре стремятся её избегать разными способами, (например, ограничивая количество персистирующих микросервисов в каждой цепочке вызовов до одного)
Разве не лучше поставить одну мощную многомониторную станцию с едиными органами управления, а проблемы с несколькими сетями решить централизованно классическими корпоративными способами — фаерволлом и разграничением доступа?
Из них обязательные траты примерно такие:
3500 — это налоги. Около 1000 — медстраховка для всей семьи. И это еще дешево. Обамакер с нашим доходом работает против нас — платим считай за себя и за того (бедного) парня.
~2000 — съем жилья с хорошими школами, свет, вода, интернет и мобильники с рассрочкой. Ипотека дороже.
1000 — две машины в лиз и страховка на них. Да, можно взять used в кредит, но выигрыш баксов в 200/mo весьма сомнителен и может запросто нивелироваться необходимостью ремонта и вынужденного простоя на работе (с этим уровнем дохода дешевле держать новую машину).
Еще желательно контрибьютить что-то в пенсию. Ну пусть $500.
Остается ~2000 на еду, одежду, детские и взрослые активити, а также на возможные дидактаблы по страховым случаям.
В сухом остатке получаем, что до 2014 года смысла переезжать из москвы только ради денег не было. Сейчас — есть.
Если один процесс пытается получить информацию о другом (о том что он запущен), то это в любом случе IPC просто по-определению этого термина. Блокируя файл, ты все-равно делаешь IPC, но не напрямую, а через посредника. Критерии «жирности», кстати, раз уж ты их упомянул, тоже дело довольно второстепенное. Хотя я не могу взять в толк, почему писать в шареную память «жирно», а на диск — нормально?
ЗЫ: Ну и по-поводу существования FHS — это тоже не аргумент. Еще в системе TCP-стек должен быть. И что теперь — давай сокет открывать по этому поводу? как альтернативу lock-файлу?:
Принципиальная проблема не в том, что ваше решение не будет работать, а в том, что для решения используются спроектированные для иных целей вещи.
В случае windows куда более логично использовать мьютекс, который по определению специально для таких целей и создан, а не городить костыли, считая любой объект в системе
гвоздёмфайлом.А linux, на сколько я знаю, для решения таких задач предполагает использование семафора на разделяемой памяти. Тоже не требующего такой сильной зависимости как разрешение на запись на диск.
И, между прочим, это каноничный пример того, как опыт создания скриптов из костылей, столь характерный для администрирования маленьких предприятий, в этом конкретном случае пошел разработчику во вред.
Ваше «решение» невозможно запустить на бездисковых системах и на системах с read-only носителями. Также потребуется решить проблемы с правами доступа приложения/пользователя на запись. Относительный путь или абсолютный — еще одна проблема. Как и API — не всякий поддерживает UNC-пути, например.
симпсонахдевзене.На самом деле спасибо за подробности