Почему в статьях про микросервисы всегда идет сравнение с монолитом? Что микросервис, что монолит — две противоположные крайности, которые имеет смысл использовать лишь иногда.
Но ведь бываюь еще, например, модульные приложения, где тесно связанные компоненты могут быть в одном относительно большом модуле с минимальным количеством внешних связей. При модульном подходе приложение можно не дробить неестественным образом на микросервисы (а потом думать как обратно их заставить работать вместе для какого-нибудь нового отчета). И опыт производителей модульного ПО (SAP, 1C и тысячи других) говорит, что этот подход тоже имеет право на жизнь.
Я практически перестал читать книги годам примерно к 35 по причине того, что все чаще и чаще стал замечать, что большинство книг помогают убить время, быстро забываются, и никак меня не меняют. И если в молодости кидался читать все, и все было интересно, то сейчас перед тем, как потратить время на чтение проверяю, а стоит ли… Например, что мне нового может мне рассказать человек младше меня на 20 лет? В области драмы и жизненных ситуаций скорее всего мало что…
Поэтому думаю вам ваша цель наскучит задолго до того, как вам станет 70.
Встречались не раз красавцы с большими запросами, им даже давали то, что они просили. Но по прошествии probation period — bye-bye по формулировке низкой эффективности.
Если начинать писать большой проект на «Чистом языке», в итоге все равно получится еще один фреймворк, так как по мере написания однотипных списков/форм приходит осознание, что у них всех есть общий код, который приходится копипастить с модификациями.
Кроме того, имеет смысл уточнить, что подразумевается под «большим проектом»:
— «большой в длину» — относительно немного относительно узких, но длинных таблиц (например соцсеть, сайт отзывов или объявлений)
— «большой в ширину» — много широких, но относительно коротких таблиц (например система ERP предприятия)
В первом случае логики обычно немного, но она должна быть очень быстрой и/или масштабируемой.
Во втором случае случае логики много и она сложная, но количество обрабатываемых сущностей не так велико.
Эти особенности тоже влияют на выбор стека. И поэтому, например, в корпорациях бизнес-процессы автоматизируют на Java, а в соцсетях используют PHP.
Возможно стоит связаться с отделами Customer Satisfaction в той же тойоте. У них такие запросы классифицируются как высоко приоритетные, особенно когда машина на гарантии, а владелец нуждается в помощи. Он мог бы, например, просто перенаправлять емайлы за какое-то вознаграждение. Понятно, что там менеджеры должны это все порешать и организовать, но это вполне реально, особенно если объемы запросов значительны.
Нельзя ценные файлы хранить в одном экземпляре, хоть локально, хоть и в облаке. Не думаю, что у гугля на бесплатные пользовательские файлы есть какие-то резервные хранилища, так как это было бы слишком дорого. Это значит, что если у них диск накрылся, то ваши данные пропали. Поэтому о дублировании придется позаботится самим. Например можно продублировать данные гугль-драйва в Dropbox или Mega.
Давно уже перестал пользоваться антивирусами. Проще при покупке компа сразу сделать бекап, а потом в случае чего восстановить все с чистого листа. А данные — в облако.
Она постепенно будет терять рынок (что происходит с той же Microsoft)
Согласен, им срочно надо что-то делать. Наблюдать эту агонию уже просто нет сил. Они уже давно созрели и перезрели чтобы внедрить систему контроля сотрудников. </сарказм>
А вообще дай бог любому стартапу умирать так, как умирает Microsoft.
Статья — хороший пример как вместо того, чтобы постоянно улучшать работу организации путем обучения персонала и внедрения нормальных бэкапов и аудита, а заменить это все имитацией, к тому же еще и демотивирующей.
А значит у системного администратора осталось время для любимой книжки.
ваша же система не даст ему возможности ее взять, а значит убивает мотивацию все настраивать чтоб работало, оставляя только мотивацию бесцельного кликания мышкой.
Стоит упомянуть, что баг фиксинг продукта обычно финансируется из Operational budget, а разработка — из Capital Budget, и что по этой причине для компании часто имеет смысл запустить сырой продукт в продакшен, но потом фиксить его и по другой, гораздо более стабильной статье расходов.
А вообще конечно, про это и так известно любому айтишнику, можно было и не дёргать 386 человек на всякую ерунду.
ITIL это сборник советов для людей о том, как построить процессы управления IT в организации. Какаким боком софт для мониторинга устройств поможет внедрить ITIL я что-то не понял: например наличие/отсутствие в организации segregation of duties, или UAT cycle, и подобных вещей, никаким боком с таким софтом не пересекается.
Кроме того, для каждой организации существует свое подмножество методов ITIL, которые для них релевантны: все зависит от размера, какаие процессы насколько критичны, условия проистекающие из законодательства, и т.п. Если бы все это сводилось толко к мониторингу устройств, но увы…
Что то я совсем ничего не понял (кроме того что глобальные переменные и eval это хорошо, а фреймворки — плохо). Наверное, проект SKY просто опережает свое время…
Очень сильно зависит от уровня незнания. Базовые вещи надо, конечно, знать
Эх, а я вот частенько гуглю базовые функции, например поиск подстроки в строке.
А все потому, что в голове конкретная каша из Java, JavaScript, PL/SQL, PHP, MS SQL, MySQL и т.д. и т.п.: где-то подсчет символов идет с 0, где-то с 1; по-разному обрабатываются NULLs, у всех разные параметры и разные допустимые значения.
Про все это можно сказать «базовые вещи», но например в мою память уже не помещаются.
IT по своей природе слишком сложно, чтобы можно было вот так вот придумать какие-то баллы, эсэлэи или другие метрики и адекватно по ним что-то оценивать.
Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.
В случае саппорта можно тоже работать на закрывание тикетов, чтобы SLA и прочие метрики соблюсти, но метрики не всегда кореллирует с удовлетворением клиента от вашей работы. И если вами недовольны, клиент с вами расстанется несмотря ни на какие баллы.
Оценка трудоемкости задач вообще отдельная тема, так как в ИТ всегда есть фактор неизвестности, обусловленный тем, что в процессе разработки могут выявиться ранее неизвестные ограничения. Например, запросто бывает, что чтобы добавить маленькую фичу в программу приходится переходить на новые версии фреймворков, решать проблемы обратной совместимости, рефакторить и переписывать работающий код.
Поэтому баллы это прикольно, но всей картины они не дают.
Вообще же, хороший тим лид обычно и без баллов знает, кто у него в команде в чем силен или слаб, и соответственно распределяет задачи по сотрудникам. И если кто-то халявит, тим лид про это уж точно будет знать.
Основная проблема таких динамических таймлапсов — стабилизация видео. Когда начинаешь монтировать все вместе, то основное время уходит именно на совмещение соседних кадров. Если соседние кадры сделаны с угловой разницей даже в 1 градус, то после стабилизации получаем трепыхания по краям (видимо обусловленные дисторцией оптики), с которыми ни Ютуб, ни прочий известный мне софт справиться не может.
Вот если бы автор решил эту проблему…
Многие важные вопросы, такие как, например, обработка ошибок сокетов, опущены.
Так ведь это самое интересное. Вам придется много-много страниц кода написать, пока у вас получится более-менее работающая реализация HTTP, и пока вы сможете начать писать бизнес-логику.
Поэтому соглашусь с предыдущими комментаторами:
Зачем?
Но ведь бываюь еще, например, модульные приложения, где тесно связанные компоненты могут быть в одном относительно большом модуле с минимальным количеством внешних связей. При модульном подходе приложение можно не дробить неестественным образом на микросервисы (а потом думать как обратно их заставить работать вместе для какого-нибудь нового отчета). И опыт производителей модульного ПО (SAP, 1C и тысячи других) говорит, что этот подход тоже имеет право на жизнь.
Поэтому думаю вам ваша цель наскучит задолго до того, как вам станет 70.
Кроме того, имеет смысл уточнить, что подразумевается под «большим проектом»:
— «большой в длину» — относительно немного относительно узких, но длинных таблиц (например соцсеть, сайт отзывов или объявлений)
— «большой в ширину» — много широких, но относительно коротких таблиц (например система ERP предприятия)
В первом случае логики обычно немного, но она должна быть очень быстрой и/или масштабируемой.
Во втором случае случае логики много и она сложная, но количество обрабатываемых сущностей не так велико.
Эти особенности тоже влияют на выбор стека. И поэтому, например, в корпорациях бизнес-процессы автоматизируют на Java, а в соцсетях используют PHP.
Согласен, им срочно надо что-то делать. Наблюдать эту агонию уже просто нет сил. Они уже давно созрели и перезрели чтобы внедрить систему контроля сотрудников. </сарказм>
А вообще дай бог любому стартапу умирать так, как умирает Microsoft.
ваша же система не даст ему возможности ее взять, а значит убивает мотивацию все настраивать чтоб работало, оставляя только мотивацию бесцельного кликания мышкой.
А вообще конечно, про это и так известно любому айтишнику, можно было и не дёргать 386 человек на всякую ерунду.
Кроме того, для каждой организации существует свое подмножество методов ITIL, которые для них релевантны: все зависит от размера, какаие процессы насколько критичны, условия проистекающие из законодательства, и т.п. Если бы все это сводилось толко к мониторингу устройств, но увы…
Эх, а я вот частенько гуглю базовые функции, например поиск подстроки в строке.
А все потому, что в голове конкретная каша из Java, JavaScript, PL/SQL, PHP, MS SQL, MySQL и т.д. и т.п.: где-то подсчет символов идет с 0, где-то с 1; по-разному обрабатываются NULLs, у всех разные параметры и разные допустимые значения.
Про все это можно сказать «базовые вещи», но например в мою память уже не помещаются.
Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.
В случае саппорта можно тоже работать на закрывание тикетов, чтобы SLA и прочие метрики соблюсти, но метрики не всегда кореллирует с удовлетворением клиента от вашей работы. И если вами недовольны, клиент с вами расстанется несмотря ни на какие баллы.
Оценка трудоемкости задач вообще отдельная тема, так как в ИТ всегда есть фактор неизвестности, обусловленный тем, что в процессе разработки могут выявиться ранее неизвестные ограничения. Например, запросто бывает, что чтобы добавить маленькую фичу в программу приходится переходить на новые версии фреймворков, решать проблемы обратной совместимости, рефакторить и переписывать работающий код.
Поэтому баллы это прикольно, но всей картины они не дают.
Вообще же, хороший тим лид обычно и без баллов знает, кто у него в команде в чем силен или слаб, и соответственно распределяет задачи по сотрудникам. И если кто-то халявит, тим лид про это уж точно будет знать.
Вот если бы автор решил эту проблему…
Так ведь это самое интересное. Вам придется много-много страниц кода написать, пока у вас получится более-менее работающая реализация HTTP, и пока вы сможете начать писать бизнес-логику.
Поэтому соглашусь с предыдущими комментаторами:
Зачем?