Все уже давно сделано - на ali ищется как bluetooth led screen, стоимость в зависимости от размера, разрешения и цвета (есть и RGB) от 20 до 80$, первый попавшийся пример
Но на домашнем VDS приложений обычно совсем не много и они гомогенные — те им вполне достаточно того, что стоит в системе.
Если же пользоваться 3rd-party решениями — типа owncloud и тд — вот тогда да — есть смысл точно, чтобы не маяться с зависимостями чужими.
Кстати про миграцию — может потому что я больше программист, чем админ — я никогда не настраиваю сервак вручную — у меня есть bash-скрипт, в котором я прописал все нужные сервисы и их конфигурации. У меня оно на Debian-е, и для того, чтобы развернуть мне сервак на новом месте, мне нужна голая система, баш и мой скрипт — я его запускаю он сам ставит пакеты, сам конфиугрирует их и сервисы, прописывает что нужно в iptables/config-ах. Да, конечно, если что-то сильно изменили — конфиг нужно будет подправить, но я стараюсь писать его так, чтобы он как можно меньше использовал спец. пакетов, а старался использовать стандартные утилиты и на моей памяти было всего один раз, когда был какой-то конфликт, связанный с обновленным пакетом. По мне — так тоже выход, причем без оверхэда. И при этом не нужно заморачиваться с конфигурацией внешней и внутренней сети докера, а самое главное — оно будет работать на vds с гораздо меньшими требованиями по памяти и цпу, что очень сильно влияет на его цену.
Я правильно понимаю, что watch с immdiate и deep куда универсальней watchEffect?
Хотя-бы потому, что не нужна пляска с бубном с развертыванием отслежиемого объекта, если нужно следить за изменением внутри объекта (как в примере массив), мало того, используя $watch его можно точно также остановить через unwatch, плюсом можно получить предыдущее состояние объетка.
По-этому мне все еще не понятно зачем нужен watchEffect…
Документация там отличная, ибо платка использована в тысячах проектов. Что до звука - не HiFi, но и у вас там не оперный зал - играет оно вполне на уровне.
Но самое главное - что мешало вообще играть не mp3, а wav? Тогда вообще без модуля бы обошлись. А карточку и плеер тянет даже ATTINY-25 (http://elm-chan.org/works/sd8p/report.html) и да, будет читать прямо с FAT.
Опять-же что мешало сделать на STM программный MP3-плеер?
№1 Зачем напротив каждого? Загружать только с одного окна, дальше должен быть кран-балка, который может оттащить груз в нужную точку цеха.
Если нет кран-балок, невозможно это сделать из-за потолков и т.д. - то, наверное, нужно подбирать новое здание под новые цели бизнеса, нет? Кроилово напомнить куда ведет?
Что до арендодателя - почти всегда можно договориться, если нельзя - значит помещение не подходит для данных задач (а не арендодатель), и надо искать другое помещение. Кроме того, обычно производственным помещениям нужна такая фишка, и если вы подпишите, что в случае чего оставите все это на месте - большинство арендодателей только обрадуется.
Что касается последствий и минимального участия человека - обычно так и думают - что ничего страшного не случится, но все учесть нельзя - например пол, на который опирается тренога, которая не может провалиться в небольшое отверстие, может обрушится или произойдет еще что-то о чем вы даже не подумали - вы ведь не знаете, как в этом месте плиты и швеллеры ложили и в каком состоянии они, правда? Это несколько преувеличено, но, я думаю, суть понятна.
№2 - это к юристам - они вам объяснят, я на вас точно жаловаться не буду)
Это все отлично и хорошо до первого ЧП с возможными жертвами.
Хитро#опость - это, конечно, именно то, что отличает нашего брата от других, но делать там в нормальном зрелом бизнесе - это очень и очень рискованно. Риски, конечно, каждый сам определяет, но всеже.
Вы ведь точно на сопромате не считали жёсткость вашей треноги? Как и всей конструкции, а также возможные варианты пиндеца? Кроме очевидных, есессно.
Плохо это все тем, что 2 раза сканает, а на третий вы либо потеряете деньги, либо репутацию, либо то и другое вместе, и хорошо, если не чьи-то жизни. А ещё успешный авось, провоцирует следующие авоси, а теория вероятности, она такая.
Делать надо так, как должно быть по ТБ, а все остальное - просто траты, но без них - никак. Но это убережет вас от очень печальных последствий. А то, что Бизнес всегда хочет сэкономить - это всегда есть, вопрос нужно ли вестись на это.
Лайфхак - один раз разборав окно и поставив туда рольставни с грязной зоной (тамбур, закрытый от основного помещения, только уже внутренними рольставнями) вы убережете себя от кучи будущей ненужной эквилибристики, рисков и трат. Но да, на хабр писать не получится.
Лайфхак №2 - не стоит писать о том, за что могут учинить проверку и выкатить штраф, превышающий как стоимость реактора, так и всего того, что было сделано. И да - статья - готовый штраф.
Не давать мешать все в одну кучу - это тоже одна из функций айти. Не должен хелпдеск внутри иметь телефонный справочник, а вот интегрирован быть с ним он должен. И как раз имея свою разработку это весьма просто делать и контролировать.
Для начала почему вы разделяете внедрение и софт? Одно без другого не существует. Мало того, затраты на второе могут стать выше затрат на первое.
Без формализации вообще ничего работать не будет, если не говорить ну уж про совсем крохотный бизнес.
Ничего уникального в процессах, естественно, нет, есть уникальность в том, как они выстроенны, и как ими управляют. Вот здесь внедрение обычно спотыкается, а внутренний софт - нет.
Насчёт тяжести, давайте для примера1С возьмём. Условную конфигурацию - половина функций там среднему и мелкому бизнесу не нужна, но она будет. Про "офигенный" их универсальный интерфейс я вообще молчу. Как оно ворочается - тоже известно.
Или например Фиделио для отелей - большинство отелей не Хаят - больше половины функционала им не нужно, но отключить это нельзя.
И оно тяжёлое не только из-за софта и фич - ведь надо людей этому всему обучать - ну вот скажите, где будет проще - где 3 понятных пункта или куча еще и со влрженностями.
Насчет SaaS и утечек - когда оно у вас, вы можете контролировать безопасность, когда не у вас - нет. Вероятность утечки от работников будут присутствовать что там, что там.
Я с разными бизнесом работал - от самого мелкого до холдингов.
У крупного как раз все проще, как и у сильно мелкого.
Обычно те, кто хотят делать что-то свое (не все), делают это по двум причинам — специфика бизнеса (хочется максимально простой и заточенный инструмент под конкретную деятельность) и вторая — быстрая и динамичная адаптация этого инструмента к реалиям с обучением сотрудников.
В моей практике с CRM я ни разу не встречался с тем, чтобы кто-то из заказчиков считал, что разработать свое дешевле. Ну, может повезло.
А вот то, что конечный инструмент получается четко под деятельность и куда удобней вести процесс обучения и интеграции — это абсолютно точно. Особенно, если уже есть IT-отдел.
Правило простое — если ваша деятельность четенько или практически четенько укладывается в какой-либо коробочный продукт, вы уверены в его дальнейшей поддержке и возможности обучения и хотя-бы минимальной заточки под себя (если это необходимо) — то можно смело брать этот продукт и не париться.
А вот если нет — то есть куча нюансов, зная которые можно и нужно делать свое.
Да, это будет не быстро и не дешево — к этому надо быть готовым.
Но зато Вы будете хозяином своих данных, доработок и продукта — что тоже очень и очень важно. А главное — доделки будут идти в разы быстрее — а это очень важно, например, для растущего бизнеса.
И никто вам не будет руки выкручивать и цены загибать и сроки нереальные ставить.
Параллельно вы отточите свой IT отдел, который потом будет заниматься вашим сайтом, интеграцией с различными системами, используемыми на фирме, с бухгалтерией, внешним API, если он нужен и тд. В конце-концов получив достаточно прозрачную и управляемую систему вашего бизнеса и перешагнете на следующий уровень.
Естественно, надо понимать целесообразность всего этого, ибо если Вы — киоск с фруктами и не мечтаете стать рынком — то смысла всего этого делать — ноль.
Про плюсы универсальных, коробочных продуктов я уже упомянул, а минусы — их там тоже тьма — среднее по рынку не подходит никому, оно тяжелое ввиду своей универсальности, как для развертки, так и для обучения, если это не трэнд рынка (как 1С напрмер), поведясь на SaaS и на облако вы отдаете безопасность и данные дяде и тд.
Есть и третье решение — можно взять бесплатный продукт и его дотачивать командой — например так делают с SugarCRM, Mantis, различными wiki, AmoCRM, различные ITIL и не ITIL хэлпдески и тд. В этом случае существенно сокращается время на разработку, продукт не болеет детскими болезнями, но вы ограничены инфраструктурой и парадигмой продукта.
Ну можно и так сказать. Просто платформа для меня — это еще и система, а не только железо. Например второй стандарт до сих пор живет активно именно под *nix-системами, под win его и не встретить щас. Ну а железо может накладывать ограничение на глубину просмотра, а также на кол-во захватываемых групп и тд.
Но вообще, если брать PCRE — то таки да, с небольшими допущениями он практически везде работает одинаково.
Регулярки — это хороший инструмент для решения определенного круга задач — если это держать в голове — проблем не будет. В реальной жизни также — попытка отверткой забивать гвозди обычно оканчивается печально.
С кроссплатформенностью тоже есть нюансы — как и любой инструмент — регулярки развивались, мало того, что там существуют как минимум два стандарта, так еще и они внутри могут отличаться — например не поддерживать именованные группы — о чем тут уже было. Не поддерживать просмотр вперед/назад (или даже отмену или включение жадности). Есть очень интересная и крутая фича современных регулярок — рекурсивные регулярки (правда она еще сложнее для понимания, чем обычные варианты) — вот она поддерживается далеко не всеми. Короче, нюансов тоже предостаточно.
Ну и суть моего комментария тоже не про JS, а про то, что придумывать себе ветряные мельницы, а потом героически с ними бороться — плохо, ибо можно было всего этого избежать и вообще не заморачиваться со всем этим.
Декомпозиция регулярок возможна как стандартными, встроенными методами (о которых я писал в первом комментарии), так и спец. инструментарием, а не дополнительными сущностями на абсолютно другом языке.
Если высокоуровневый язык дает хорошие преимущества — почему бы и нет? Олдфаги здесь не причем, это простая рациональность.
А вот если преимущество сводится лишь к тому «хочу, чтобы было так, как я знаю сейчас и как мне удобно, а как там было до меня — все равно» — это, ИМХО, тупик.
В современном мире программисты стараются из кубиков складывать, а в нутро не лезть) Тем более — новые программисты. Есть такие вещи, которые не в тренде — регулярки именно оттуда.
На одной из конференций в 2021 делали опрос про регулярки — примерно 60% их знало, около 35% могли писать что-то, и только около 8% понимали как оно работает. А теперь внезапно возраст — первая группа 18-45, вторая — 20-45, третья 29-45. Так что увы и ах.
Это, естественно, не означает какую-то оценку ума — это лишь означает важность опыта. Я встречал и 18-летнего дева, который в регулярках был, как в своем родном болоте — просто потому, что ему было интересно, и он на системника учился — но это скорее исключение, чем правило.
А вот попытки перетащить то, что надо просто понимать в то, в чем ты уже понимаешь — это как раз черта новых программистов — не в обиду вам будет сказано. Это как вечные попытки натянуть классическое ООП на JS с прототипами, хотя последнее при понимании отнюдь не хуже. Ну и из-за количества этих программистов в конце-концов в JS таки втянули это дело, до регулярок пока не добрались т-т-т )
Все ИМХО:
Вы со следствием боритесь, а не с причиной.
Все уже давно сделано - на ali ищется как bluetooth led screen, стоимость в зависимости от размера, разрешения и цвета (есть и RGB) от 20 до 80$, первый попавшийся пример
Но на домашнем VDS приложений обычно совсем не много и они гомогенные — те им вполне достаточно того, что стоит в системе.
Если же пользоваться 3rd-party решениями — типа owncloud и тд — вот тогда да — есть смысл точно, чтобы не маяться с зависимостями чужими.
Кстати про миграцию — может потому что я больше программист, чем админ — я никогда не настраиваю сервак вручную — у меня есть bash-скрипт, в котором я прописал все нужные сервисы и их конфигурации. У меня оно на Debian-е, и для того, чтобы развернуть мне сервак на новом месте, мне нужна голая система, баш и мой скрипт — я его запускаю он сам ставит пакеты, сам конфиугрирует их и сервисы, прописывает что нужно в iptables/config-ах. Да, конечно, если что-то сильно изменили — конфиг нужно будет подправить, но я стараюсь писать его так, чтобы он как можно меньше использовал спец. пакетов, а старался использовать стандартные утилиты и на моей памяти было всего один раз, когда был какой-то конфликт, связанный с обновленным пакетом. По мне — так тоже выход, причем без оверхэда. И при этом не нужно заморачиваться с конфигурацией внешней и внутренней сети докера, а самое главное — оно будет работать на vds с гораздо меньшими требованиями по памяти и цпу, что очень сильно влияет на его цену.
Вот, например, стандартный VDS стандартного IT-шика: там, обычно nginx/apache/lhttpd + python/php/node + OpenVPN/WG и все — смысл там ставить докер?
Разве что если на нем хостить публичный сайт, чтобы если root-а получат, не вылезли из гостевой оси… ну такое.
Ошибаюсь?
Ростелеком и ВПН и ГОСТ - прямо все звезды сошлись - точно будет безопасно - вопрос - для кого?
Ну вот разве что события, опять-же этого можно добиться в watch через nextTick нет?
Хотя-бы потому, что не нужна пляска с бубном с развертыванием отслежиемого объекта, если нужно следить за изменением внутри объекта (как в примере массив), мало того, используя $watch его можно точно также остановить через unwatch, плюсом можно получить предыдущее состояние объетка.
По-этому мне все еще не понятно зачем нужен watchEffect…
Документация там отличная, ибо платка использована в тысячах проектов. Что до звука - не HiFi, но и у вас там не оперный зал - играет оно вполне на уровне.
Но самое главное - что мешало вообще играть не mp3, а wav? Тогда вообще без модуля бы обошлись. А карточку и плеер тянет даже ATTINY-25 (http://elm-chan.org/works/sd8p/report.html) и да, будет читать прямо с FAT.
Опять-же что мешало сделать на STM программный MP3-плеер?
№1 Зачем напротив каждого? Загружать только с одного окна, дальше должен быть кран-балка, который может оттащить груз в нужную точку цеха.
Если нет кран-балок, невозможно это сделать из-за потолков и т.д. - то, наверное, нужно подбирать новое здание под новые цели бизнеса, нет? Кроилово напомнить куда ведет?
Что до арендодателя - почти всегда можно договориться, если нельзя - значит помещение не подходит для данных задач (а не арендодатель), и надо искать другое помещение. Кроме того, обычно производственным помещениям нужна такая фишка, и если вы подпишите, что в случае чего оставите все это на месте - большинство арендодателей только обрадуется.
Что касается последствий и минимального участия человека - обычно так и думают - что ничего страшного не случится, но все учесть нельзя - например пол, на который опирается тренога, которая не может провалиться в небольшое отверстие, может обрушится или произойдет еще что-то о чем вы даже не подумали - вы ведь не знаете, как в этом месте плиты и швеллеры ложили и в каком состоянии они, правда? Это несколько преувеличено, но, я думаю, суть понятна.
№2 - это к юристам - они вам объяснят, я на вас точно жаловаться не буду)
Это все отлично и хорошо до первого ЧП с возможными жертвами.
Хитро#опость - это, конечно, именно то, что отличает нашего брата от других, но делать там в нормальном зрелом бизнесе - это очень и очень рискованно. Риски, конечно, каждый сам определяет, но всеже.
Вы ведь точно на сопромате не считали жёсткость вашей треноги? Как и всей конструкции, а также возможные варианты пиндеца? Кроме очевидных, есессно.
Плохо это все тем, что 2 раза сканает, а на третий вы либо потеряете деньги, либо репутацию, либо то и другое вместе, и хорошо, если не чьи-то жизни. А ещё успешный авось, провоцирует следующие авоси, а теория вероятности, она такая.
Делать надо так, как должно быть по ТБ, а все остальное - просто траты, но без них - никак. Но это убережет вас от очень печальных последствий. А то, что Бизнес всегда хочет сэкономить - это всегда есть, вопрос нужно ли вестись на это.
Лайфхак - один раз разборав окно и поставив туда рольставни с грязной зоной (тамбур, закрытый от основного помещения, только уже внутренними рольставнями) вы убережете себя от кучи будущей ненужной эквилибристики, рисков и трат. Но да, на хабр писать не получится.
Лайфхак №2 - не стоит писать о том, за что могут учинить проверку и выкатить штраф, превышающий как стоимость реактора, так и всего того, что было сделано. И да - статья - готовый штраф.
Не давать мешать все в одну кучу - это тоже одна из функций айти. Не должен хелпдеск внутри иметь телефонный справочник, а вот интегрирован быть с ним он должен. И как раз имея свою разработку это весьма просто делать и контролировать.
Для начала почему вы разделяете внедрение и софт? Одно без другого не существует. Мало того, затраты на второе могут стать выше затрат на первое.
Без формализации вообще ничего работать не будет, если не говорить ну уж про совсем крохотный бизнес.
Ничего уникального в процессах, естественно, нет, есть уникальность в том, как они выстроенны, и как ими управляют. Вот здесь внедрение обычно спотыкается, а внутренний софт - нет.
Насчёт тяжести, давайте для примера1С возьмём. Условную конфигурацию - половина функций там среднему и мелкому бизнесу не нужна, но она будет. Про "офигенный" их универсальный интерфейс я вообще молчу. Как оно ворочается - тоже известно.
Или например Фиделио для отелей - большинство отелей не Хаят - больше половины функционала им не нужно, но отключить это нельзя.
И оно тяжёлое не только из-за софта и фич - ведь надо людей этому всему обучать - ну вот скажите, где будет проще - где 3 понятных пункта или куча еще и со влрженностями.
Насчет SaaS и утечек - когда оно у вас, вы можете контролировать безопасность, когда не у вас - нет. Вероятность утечки от работников будут присутствовать что там, что там.
Я с разными бизнесом работал - от самого мелкого до холдингов.
У крупного как раз все проще, как и у сильно мелкого.
Обычно те, кто хотят делать что-то свое (не все), делают это по двум причинам — специфика бизнеса (хочется максимально простой и заточенный инструмент под конкретную деятельность) и вторая — быстрая и динамичная адаптация этого инструмента к реалиям с обучением сотрудников.
В моей практике с CRM я ни разу не встречался с тем, чтобы кто-то из заказчиков считал, что разработать свое дешевле. Ну, может повезло.
А вот то, что конечный инструмент получается четко под деятельность и куда удобней вести процесс обучения и интеграции — это абсолютно точно. Особенно, если уже есть IT-отдел.
Правило простое — если ваша деятельность четенько или практически четенько укладывается в какой-либо коробочный продукт, вы уверены в его дальнейшей поддержке и возможности обучения и хотя-бы минимальной заточки под себя (если это необходимо) — то можно смело брать этот продукт и не париться.
А вот если нет — то есть куча нюансов, зная которые можно и нужно делать свое.
Да, это будет не быстро и не дешево — к этому надо быть готовым.
Но зато Вы будете хозяином своих данных, доработок и продукта — что тоже очень и очень важно. А главное — доделки будут идти в разы быстрее — а это очень важно, например, для растущего бизнеса.
И никто вам не будет руки выкручивать и цены загибать и сроки нереальные ставить.
Параллельно вы отточите свой IT отдел, который потом будет заниматься вашим сайтом, интеграцией с различными системами, используемыми на фирме, с бухгалтерией, внешним API, если он нужен и тд. В конце-концов получив достаточно прозрачную и управляемую систему вашего бизнеса и перешагнете на следующий уровень.
Естественно, надо понимать целесообразность всего этого, ибо если Вы — киоск с фруктами и не мечтаете стать рынком — то смысла всего этого делать — ноль.
Про плюсы универсальных, коробочных продуктов я уже упомянул, а минусы — их там тоже тьма — среднее по рынку не подходит никому, оно тяжелое ввиду своей универсальности, как для развертки, так и для обучения, если это не трэнд рынка (как 1С напрмер), поведясь на SaaS и на облако вы отдаете безопасность и данные дяде и тд.
Есть и третье решение — можно взять бесплатный продукт и его дотачивать командой — например так делают с SugarCRM, Mantis, различными wiki, AmoCRM, различные ITIL и не ITIL хэлпдески и тд. В этом случае существенно сокращается время на разработку, продукт не болеет детскими болезнями, но вы ограничены инфраструктурой и парадигмой продукта.
Но вообще, если брать PCRE — то таки да, с небольшими допущениями он практически везде работает одинаково.
С кроссплатформенностью тоже есть нюансы — как и любой инструмент — регулярки развивались, мало того, что там существуют как минимум два стандарта, так еще и они внутри могут отличаться — например не поддерживать именованные группы — о чем тут уже было. Не поддерживать просмотр вперед/назад (или даже отмену или включение жадности). Есть очень интересная и крутая фича современных регулярок — рекурсивные регулярки (правда она еще сложнее для понимания, чем обычные варианты) — вот она поддерживается далеко не всеми. Короче, нюансов тоже предостаточно.
Ну и суть моего комментария тоже не про JS, а про то, что придумывать себе ветряные мельницы, а потом героически с ними бороться — плохо, ибо можно было всего этого избежать и вообще не заморачиваться со всем этим.
Декомпозиция регулярок возможна как стандартными, встроенными методами (о которых я писал в первом комментарии), так и спец. инструментарием, а не дополнительными сущностями на абсолютно другом языке.
Грубо — все это очень сильно зависит от среды и языка — фишка в том, что вполне можно обойтись без этого и вообще не напрягаться по этому поводу.
А вот если преимущество сводится лишь к тому «хочу, чтобы было так, как я знаю сейчас и как мне удобно, а как там было до меня — все равно» — это, ИМХО, тупик.
На одной из конференций в 2021 делали опрос про регулярки — примерно 60% их знало, около 35% могли писать что-то, и только около 8% понимали как оно работает. А теперь внезапно возраст — первая группа 18-45, вторая — 20-45, третья 29-45. Так что увы и ах.
Это, естественно, не означает какую-то оценку ума — это лишь означает важность опыта. Я встречал и 18-летнего дева, который в регулярках был, как в своем родном болоте — просто потому, что ему было интересно, и он на системника учился — но это скорее исключение, чем правило.
А вот попытки перетащить то, что надо просто понимать в то, в чем ты уже понимаешь — это как раз черта новых программистов — не в обиду вам будет сказано. Это как вечные попытки натянуть классическое ООП на JS с прототипами, хотя последнее при понимании отнюдь не хуже. Ну и из-за количества этих программистов в конце-концов в JS таки втянули это дело, до регулярок пока не добрались т-т-т )