№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 таки втянули это дело, до регулярок пока не добрались т-т-т )
То, к чему привыкли — очень ценно. Привычки, знаете-ли тяжело менять — что в интерфейсах, что в программировании. И если и менять — то должен быть очень веский повод для этого.
В приведенном вами варианте регулярка становится размазанной по коду, начинает зависеть от еще одного языка иперестает быть воспринимаемой как регулярка и читаемости прибавляется только на последнем шаге при сборке — оно того ИМХО не стоит никаким образом, тем более — не стоит того чтобы менять устоявшиеся практики, ибо минусов куда больше, чем плюсов.
Знаете, все, конечно, ИМХО. Но я занимаюсь регулярками практически с самого их появления, и то, что Вы описали в статье — скорее вред, чем польза.
Обьясню почему — вы привнесли в регулярки еще один язык высокого уровня, который во-первых замедляет их выполнение, во-вторых лишает кроссмплатформенности и быстроты проверки. Да, я понимаю, что можно в конце концов вытащить итоговое выражение и оно будет работать везде — но его еще собрать надо.
Кроме того, большинство программистов привыкли именно к такому виду, который Вы показали в начале статьи + есть огромное количество инструментов для визуализации и работы с регулярками.
Если хочется более-менее порядка и стройности в данных выражениях, то для этого есть флаг PCRE-EXTENDED и после этого у вас появляется возможность использовать пробелы, табуляцию и перевод строки для разделения кусков регулярного выражения, возможность писать комментарии, а если совместить это с именованием групп — то вообще все будет с читаемостью отлично. И при этом никаких лишних сущностей не требуется.
Ну и в результате те, кто применяют регулярки редко точно не будут заниматься тем, что описано в статье, а те, которые с ними работают часто — точно также не будут этого оделать, так как есть стандарт + инструменты + опыт взаимодействия со всем этим — и то, что описано у вас, будет восприниматься как пятая нога.
Когда я выгляжу как супергерой, я и действую по-супергеройски — быстро и точно.
Простите за занудство - а я всегда думал, что в кибербезе мозг - это главное, а то, как ты выглядишь - вообще роли не играет - ибо тебя никто и не видит толком, да и не должен.
Вроде бы серьёзные намерения у конторы, серьезный бизнес (о чем упоминалось не раз в статье), я бы даже сказал, что серьёзнее деятельность в IT не найти - и при этом супергерои... Как потом к вам серьезно-то и по взрослому относится?
Читатешь и не понимаешь - толи это шутка какая-то, то ли пиар неумелый и попытка хантить молодежь (из цикла: а у нас есть печеньки), толи реально такое.
Если я верно посмотрел на Amazon, то AMD может взять примерно за 190$, тогда как Intel за 275$, разница в 85$ точно не стоит разницы в синтетических попугаях и AMD тут сильно выигрывает.
Имелось ввиду, что при текущих способах прототипирования, вполне возможно производить небольшую партию корпусов. В моем случае это были промышленные 3d-принтеры, с последующим пескоструем. Но также возможно изготовление по 3d-модели сликонки и литье небольших партий в нее из разрешенных материалов (цинк, резина и тд).
Фрезеровка — это изготовление корпусов путем фрезеровки того, что можно фрезеровать — из алюма (или другого металла), G10, гетинакса и тд — для небольшой партии (особенно — штучной) это будет куда дешевле разработки ПФ, мало того, из металла корпус еще и смотрится приятней, чем из пластика.
№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 таки втянули это дело, до регулярок пока не добрались т-т-т )
В приведенном вами варианте регулярка становится размазанной по коду, начинает зависеть от еще одного языка иперестает быть воспринимаемой как регулярка и читаемости прибавляется только на последнем шаге при сборке — оно того ИМХО не стоит никаким образом, тем более — не стоит того чтобы менять устоявшиеся практики, ибо минусов куда больше, чем плюсов.
Обьясню почему — вы привнесли в регулярки еще один язык высокого уровня, который во-первых замедляет их выполнение, во-вторых лишает кроссмплатформенности и быстроты проверки. Да, я понимаю, что можно в конце концов вытащить итоговое выражение и оно будет работать везде — но его еще собрать надо.
Кроме того, большинство программистов привыкли именно к такому виду, который Вы показали в начале статьи + есть огромное количество инструментов для визуализации и работы с регулярками.
Если хочется более-менее порядка и стройности в данных выражениях, то для этого есть флаг PCRE-EXTENDED и после этого у вас появляется возможность использовать пробелы, табуляцию и перевод строки для разделения кусков регулярного выражения, возможность писать комментарии, а если совместить это с именованием групп — то вообще все будет с читаемостью отлично. И при этом никаких лишних сущностей не требуется.
Ну и в результате те, кто применяют регулярки редко точно не будут заниматься тем, что описано в статье, а те, которые с ними работают часто — точно также не будут этого оделать, так как есть стандарт + инструменты + опыт взаимодействия со всем этим — и то, что описано у вас, будет восприниматься как пятая нога.
Простите за занудство - а я всегда думал, что в кибербезе мозг - это главное, а то, как ты выглядишь - вообще роли не играет - ибо тебя никто и не видит толком, да и не должен.
Вроде бы серьёзные намерения у конторы, серьезный бизнес (о чем упоминалось не раз в статье), я бы даже сказал, что серьёзнее деятельность в IT не найти - и при этом супергерои... Как потом к вам серьезно-то и по взрослому относится?
Читатешь и не понимаешь - толи это шутка какая-то, то ли пиар неумелый и попытка хантить молодежь (из цикла: а у нас есть печеньки), толи реально такое.
Ещё интересный фактор - это цена на них.
Если я верно посмотрел на Amazon, то AMD может взять примерно за 190$, тогда как Intel за 275$, разница в 85$ точно не стоит разницы в синтетических попугаях и AMD тут сильно выигрывает.
Фрезеровка — это изготовление корпусов путем фрезеровки того, что можно фрезеровать — из алюма (или другого металла), G10, гетинакса и тд — для небольшой партии (особенно — штучной) это будет куда дешевле разработки ПФ, мало того, из металла корпус еще и смотрится приятней, чем из пластика.