неа. один экран окна настроек.
Вот кстати, настройка на корпоративный Exchange может утомить. В самом аутлуке два поля — адрес сервера и логин. Но в связи с шифрованием могут быть нюансы — после установки сертификата адрес сервера будет не тот, какой вы думаете.
Эта статья — очередное доказательство, что линуксу не стать офисной машиной.
Для сравнения приложили бы настройку аутлука — там 3 клика, ввод почты/пароля и 5 сек ожидания.
И маленький такой моментик — OWA может быть выключен с большой долей вероятности на корпоративных серверах. И все эти приблуды сразу не работают.
Вы сами перечитайте свои комментарии — это даже не компромисы. Вы просто терпите! Едите кактус и терпите.
Нет встроенного календаря, нет иконки в трее, нет нормальной адресной книги или она виснет, календарь не работает или глючит. Инструкция по подключению на 10 листах!!!
К аутлуку какие претензии то после этого? У него все работает.
Вроде как не маленькая статья, а ни о чем.
При выборе базы данных первый вопрос не что и как хранить, вы на него потом найдете ответ, а что вам надо с данными делать.
Если вам ничего с ними делать не надо, то и хранить их не надо. База данных не нужна.
Если вам надо посмотреть на них справа, потом сверху, потом посчитать вхождение «этого» в «то», средние, промежуточные итоги — то без SQL это очень затруднительно. Как минимум закончится изобретением миниSQL на коленке.
Если вам надо записать много данных, а потом их просто показать, целиком или кусками — то можно пробовать NoSQL. Но как только у вас появятся дополнительные требования к фильтрованию и связям — то вы постепенно начнете смотреть в сторону SQL — там уже есть ответы на многие ваши ещё не заданные вопросы.
Характерно, что сам вопрос о NoSQL встал на повестку дня когда память стала доступна гигабайтами и не надо заморачиваться быстродействием — положил базу в память и все.
Истина посредине. Для хранилища котиков подойдет NoSQL, т.к. зачастую записей будет больше, чем чтения. При этом взаимосвязи авторов котиков будут храниться в SQL, а сам SQL ещё разделится на горячие и холодные данные.
Кроме этого, NoSQL, как и другие не типизированные средства разработки, выполняет социальную функцию — легкий вход в программирование широких масс населения, оставляя вопросы типов и структур данных для тех, кто прошел идиотентест простых ответов на простейшие вопросы.
Иначе нельзя объяснить «преимущество» NoSQL — «отсутствие жесткой структуры данных». Это как же вы с данными работать будете если не знаете что там? По сути, под каждый кейс данных писать парсер и распознавать содержимое.
где-то с 80-х годов было подмечено, что производительность специалистов уровня от среднего и выше не зависит от зарплаты. Отсюда все эти социальные пакеты, игровые комнаты в офисах, 20% на личные проекты и прочая неденежная мотивация.
Так что вы скорее всего разработчик ниже среднего или зарабатываете очень мало относительно в среднем по рынку.
Привязка к соцсетям относительно безопасна, если там есть двухфакторная авторизация. Однако большинство соцсетей настолько несерьезны по содержанию, что не хочется привязывать их к рабочим или конфиденциальным данным — социальная инженерия и последующий терморектальный криптоанализ рулят.
Раздражающие правила по паролям приходится обходить с помощью браузера, который запоминается все внесенные пароли, которые потом можно посмотреть (maxthon). А кому от этого легче? Это та же бумажка с паролем, приклеенная к монитору.
Лехко. Какие-то странные люди, которые до этого делали Delphi, а затем c#, придумали TypeScript. Так вот сам попробовал: 90% глюков отлавливается на этапе компиляции остается только вопрос неправильнлого алгоритма.
Ещё одни странные люди, сменив версию Ангулара с 1 на 2, тоже перешли на TypeScript (жесткая типизация). Наверное, им надоело есть кактус.
Вы не совсем правы. Экономисты не имеют отношения к обратной связи, и очень косвенное — к системе мотивации. Негативный вклад экономисты тем, что изначальную систему сбалансированных ПОКАЗАТЕЛЕЙ ОЦЕНКИ подменили системой целей, которая один в один списана с тех показателей.
А вот кто реально уничтожает компании и их персонал всеми этими оценками — это хр-директора и менеджеры во всяких KPI и системах оплаты труда на их основе.
А правило Гудхарта очень быстро, за пару месяцев, выводится любым сотрудником, у которого зарплата зависит от KPI — как только ему поставлены ВАЖНЫЕ показатели, все остальные сразу становятся НЕВАЖНЫМИ. При этом общее качество работы и системы работы его не волнует — «жираф большой, ему видней».
скажите, сколько памяти занимает ваше трехстрочное приложение поле получаса работы?
Сам попробовал электрон, но на второй день снес — дешевле в пкстую форму приложения на дельфи7 поставить браузер на всю форму, а страницы и всё остальное зашить в ресурсы (ИЕ он и так умеет)
Дешево и сердито.
Глядя на это вспомнилась технология xml/xsl, котрая работала 15 лет назад в ИЕ.
Там все тоже самое — можно сделать шаблоны для собственного тега с обработкой вложенных в свой тег дочерних элементов.
Годная вещь была, немного сложноватая на старте.
Однако, проблема таже самая, что и до сих пор — js код никак не привязан к элементам браузера и приходилось придумывать лисапеды по навешиванию событий на сгенерированный html, чтобы в итоге работать с тегом как с объектом.
Когда нибудь web components сделают переворот в разработке. Когда-нибудь. А пока 15 лет потрачены на непонятно кому нужные новые стандарты и языковую вкусовщину, которая почему перекомпилируется в древний js.
Забавно смотреть на ИТ-отрасль, особенно из-за того, что в ней много творческих, увлеченных людей. «К разработчикам надо относиться как к детям» — к сожалению, этим пользуются ушлые менеджеры.
Каждая новая методика или технология воспринимается как панацея.
Но, кроме творчества и влеченности, отличетельной чертой ИТ-отрасли являлется очень узкий гругозор.
Я хочу сказать, что большинство «новых» методик и технологий имеют возраст в несколько десятков лет и 2-3 итерации забвения.
Приведу примеры «килер-фич» из смежной области, управленческого менеджента:
— «ABC-costing». 10-15 лет назад: методика управления накладными расхода. Куча книг, десятки семинаров, много проектов по внедрению. Результат — она забыта. Причина — ни одго успешного проекта внедрения.
— KPI — медодика управления предприятием с использованием «ключевых показателей». Изначально выглядела как некий dush-board предприятия — по 4-5 показателя на производство, финансы, маркетинг и персонал. За посление 15 лет доведена до абсурда — по сути превратилась во внедрение «сдельщины» по всех профессиях. Много компаний превратились в «террариум единомышленников» благодаря этому.
— «описание бизнес-процессов» — здравая в начале идея доведена до бюрократического формализма — к моменту завершания описания всех процессов и создания по ним инструкций компании может уже и не быть. Реально работает в узких отраслях и подсистемах — СМК ISO9000 и низовые процессы по исполнителям при разработке ПО.
— «бюджетирование» — старая как мир идея в очередной раз полюбилась публике 15 лет назад, когда новын бизнесмены прочитали такое в газетах (о том, что оно десятилетиями работало — они ещё не знали). Запустилось множество проектов во многих странах и компаниях. В текущий момент идея жива в кулуарах — реальные работающие системы бюджетирования не выходят дальше Экселя и конкретных людей, знающих специфику именно этой компании и её продукцтов. Ни одной общепринятой технологической платформы все ещё нет.
— «20% времени на личные проекты» — можная фишка для модной компании. Став корпорацией, Гугел как-то незаметно прикрыл лавочку.
В общем, ко всем этим «модным» технлогиям надо выждать время — года 2-3, а лучше 5. В большинстве случаев они перестаю быть модными и исчезают.
Пока ещё не опровергнута классика управления: стратегические цели — план их достижения пошагово — цели и задачи на каждом шаге — тактика по достижению локальных целей и задач.
Имеено по этому шаблону надо оценивать метолики и теории и определять их место.
Отсюда же связка Проектант — инженер — прораб — строитель, ой, CTO — продакт менеджер — проджект менеджер — разработчик.
Почти все таории, описанные выше, пытались покрыть эту цепочку частично или целиком.
Кратко по скруму — это так называемый «простой неправильный ответ на сложный вопрос».
Состоит он из смеси атомарных бизнесс-процессов, обещания счастья для неспециалистов и KPI в творческих профессиях. Уже сам набор компонентов вызывает скепсис по жизнепособности: про стратегию нет вообще ни слова, голая тактика на 2 недели с отжимом продуктивности по KPI — сомнительная на марафонской дистанции аврально-потогоная система.
Ага. Начинаем определяться с терминами.
Суть статьи в следующем.
Придумываем 4-хзвенную технологию.
Звено 1 — база данных
Звено 2 — сервер, которые генерит данные из базы наружу. Сейчас это можно слово «RAST»
Звено 3 — сервер, который генерит шаблон страницы в HTML с помощью js. Это костыль данной технологии — генерацию страницы уже не знаю куда приткнуть: typescript(чтобы можно было больше 3-х файлов написать коллективом более 2-х человек) + babel (потому что нужен прогресс ради прогресса без понятного результата) + framework1-2-3 (костыли для компонентной разработки, потомоу что HTML убог и примитивен). Если выйти за рамки JS, то это все всякие разные PHP/Python/CGI спокойно делают это последние 20 лет без особых заморочек.
Звено4 — браузер, который получив шаблов HTML, подгружает скрипты и страница работает.
Всяя суть статьи в том, что звенья 3 и 4 вы можете сделать в браузере. По своему желанию — или так, или так.
Только особенность технологии JS — если сделать все браузере, то он ставит современные компы на колени (напримет тотже atom за 3-4 час а рабоыт выжирает несколько Гб оперативки на паре открытых файлов по 10 кб).
Итогог, ИЗОМОРФНЫЙ = костыль JS.
Если это слово убрать, то PHP/Python/C++/Pascal + JS — тоже можно, только модные слова типа React, Angular, ES6 — проходят мимо и остается просто работа.
Кстати, судя по статьям на хабре, технология фремворков JS деградирует — ответа, на чем писать, нет даже приблизительно, есть лишь разные варианты БДСМ.
ЗЫ. Подсказываю, как и коментатор ниже — проблема в браузере как стеке технологий.
изоморфные приложения на с++ 20 лет назад называлось CGI.
И может я че-то не понимаю… Раньше все скидывали на клиент, чтобы сервер меньше считал. А теперь типа все назад на сервер, потмоу что ОДИН клиент не тянет. А сервер значит 1000 клиентов — легко.
И вот что ещё странно. На клиенте утечка памяти есть, а на сервере на 1000 подключений на томже самом стеке технологий не будет… Странно.
А как дебажить эти ваши изоморфные приложения???
в статье намешали кучу вопросов, которые лишь косвенно связаны между собой.
Вопрос 1. Консультанты. Феномен консультантов вызван неколькими факторами:
а) крайне низкий уровень понимания теории и практики управления и экономики собственников бизнеса и топ-менеджеров в среднем и особенно крупном бизнесе. Как ни странно это звучит. У кого-то бизнес вдруг удался, не смотря на персоналии, кто-то залез в кресло босса нетрудовыми успехами. В таких случаях людям льстит, что человек знающий много умных слов и имеющий корочку МБА, находится в позиции подчиненного и более того — заискивающего, т.к. надо убедить подписать контракт и поэтому консультанты рассказывать будут что угодно и обещать тоже.
б) с помощью консультантов топ-менеджмент или собвенники хотят продвинуть какую-то свою идею и подвинуть или перетряхнуть подчиненных или параллельные службы
в) это модно. Дорогим галстуком или машиной уже не удивить. А вот типа пригласить консультантов — это да, это типа мы такие продвинутые и типа развиваем бизнес до заоблачных высот.
Вопрос 2. Почему консультанты довольно часть — вред. Сюда же запишет и разных внедренчев — вред одинаковый.
а) в статье уже сказано — это бывают люди, торгующие лицом, которые не могут принести пользу как работники. Практикуется «чайка-менеджмент».
б) консультанты давят авторитетом, не учитывают требования заказчика, потому что считают, что они умнее — в итоге разламывают то что есть, а новое собрать способностей не хватает.
в) продукт или методика, которые внедряются — слишком тяжело настраивать или требует много знаний и труда. И поэтому начинают впихивать стандартные методики — все что в них не влазит — выкидывается
Вопрос 3. А необходим ли КПИ?
Тут надо понимать такие вещи:
а) норма управляемости. Это 5-7 человек на одного управленца. Если человек больше — надо делегировать, и приэтом надо как-то контролировать того, кому делегированы полномочия И КПИ нужен в каком-то виде.
б) когда вы не можете добросить дыроколом в каждого своего работника — тоже как-то надо понимать, что он там делает
в) надо своим умом дойти до того, что вам нужен КПИ. Собственнику и топ-менедженту надо учиться, учиться и учиться. Ситуация в статье — «книги читать некогда, но нужен КПИ» — это заранее провальный проект, никакое ПО его не вытянет. Это как дать планшет маленькому ребенку — до определенного момента об будет успешно тыкать пальцен, но рано или поздно будет озадачен непониманием.
г) в малом бизнесе КПИ очень простой — наличие живых денег у соственника. Если денег нет — надо срочно предпринимать корректирующие действия.
д) в среднем бизнесе необходимоть КПИ определяется 2 факторами: пониманием что это такое и как работает и узкой специализацией людей, к которым применяется КПИ.
Вопрос 4. Какой вред от КПИ?
КПИ работает только тогда, когда функции четко поделены и они однообразны для каждого человека.
Сама суть «ключевые показатели», за которые вы платите деньги — автоматически переводит все остальные показатели в «неключевые». Не надо считать своих работников глупыми, они очень быстро приспособятся.
Отсюда проблема со сдельно работой — страдает качество
Отсюда пролблема с процентом от продаж — может упасть маржа и прибыль
Надо четко понять, что именно будет «ключевым », а чем люди будут пренебрегать
И именно поэтому любое совмещение одним человеком 2-3-4 функции запрещает применение КПИ — вы угробите и работу и человека.
Ээээ, кхм…
Это хорошо, что сделали типа ВПР, но через ПОИСКПОЗ, хотя в первоначальной статье именно про это в коментариях и говорилось.
Однако…
Функции пита ВПР или ПОИСКПОЗ прменяются в 2-х видах задач:
1. Разовая обработка больших массивов данных в экселе. Как оказала практика, если вы через ОЛЕ выгружаете данные эксель, то лучше выгружать сразу в Аксес. Для статитстической обработки очень больших данных это намного практичнее и быстрее.
Более того, если выгружать в эксель и обрабатывать в нем, то нюансы функции ВПР не так важны, как и скорость — работа разовая, можно 1- сек подождать.
2. Рабочие файлы, в которых ежедневно, ежеднелельно и ежемесячно ведется работа, обрабатываемые данные могут заносится туда выгрузками или вручную (т.е. никаких сортировок).
И функции типа ВПР, ПОИСПОЗ или СУММПРОИЗВ применяются в массовых масштабах для создания реляционной базы.
Данные измеряются не 200 тыс строк, а на порядок меньше, зато указанные функции используются по 5-15 раз в каждой строке, итого они вызываются под 1 млн раз.
Это я к чему? При такое количестве вызоов функций любое использование ВБА подвешивает программу на минуты и часы. По этой простой причине примеются исключительно встроенные фукнции, т.к. скрипты катасрофически тормознутые.
Если у вас 100 вызовов ВБА — это нормально, если 100 тыс. — это беда.
Причем тормозит именно сам механизм ВБа, даже если вы там внутри вызываете встроенные функции.
«Итого, ВПР проигрывает ИНДЕКС+ПОИСКПОЗ только по требованию «ищу только в первом столбце».»
Также он проигрывает ещё в критичной зависимости к структуре данных. Добавление одного столбца в таблицу данных может все поломать.
Кстати, в стетьях, на которые ссылается автор, сравниваются в том числе и ВПР и ИНДЕКС+ПОИСКПОЗ. Вторая связка произрывает на 5-10% (на данных в 200 тыс строк 50 сек вместо 45), что не критично, зато поддерживает целостность данных.
«1. Не сосем согласен с вами. Если в формулу последним параметром ставить «0» («ЛОЖЬ») то поиск ведется до победного и сортировка для ВПР не нужна».
Это понятно. Но тут ведь описывается вундервафля с ускорением в 25 раз. Только кто-то должен не забыть отсортировать данные. Для разовой обработки набора данных — пойдет. Для рабочего файла, которые используется регулярно, да ещё и несколькими пользователями — это выстрел в ногу. Такойже как сводные таблицы.
Кстати, ни автор статьи, ни в тех статья, на которые он ссылается, не указывается, за сколько с задачей справится сводная таблица — это может быть самый простой путь для разовой обработки данных.
Вообще, для разработки именно приложений многократного использования пока лучше всего показывают себя СУММПРОИЗВ (быстрее, но требуют данных одинакового размера) и формулы массивов (они медленне, но позволяют разноразмерные данные) в связке с таблицам (именование области данных с именованными столбцами)
Так делаем, когда надо получить текстовое значение, т.е. без агрегатных функций. Обычно в таких слкчаях наборка небольшая (сотни-тысячи записей), поэтому скорость не критична.
Например, 3 столбца отбора, 1 столбец данных. Добавляем 5-й столбец, который соединяет значения этих 3-х столбцов отбора: = СЦЕПИТЬ(Столбец1;"-"; Столбец2;"-"; Столбец3)
Потом при поиске пишем =Индекс(Столбец4; ПОИСКПОЗ(СЦЕПИТЬ(Условие1;"-"; Условие2;"-"; Условие3); Столбец5;0))
ВПР, к сожалению, требует слишком много условий для нормальной работы:
— ключ в первом столбце
— ключ сортированный по возврастанию
— повторый ключа вносят неопределенность
Для составления чего-то, похожего на реляционную базу с контролем ошибок неприменима.
Поэтому
— либо СУММПРОИЗВ — для работы с числовыми результирующими столбами и отбор по любому количеству параметров
— либо связка ПОИСКПОЗ+СЦЕПИТЬ+ИНДЕКС — для опятьже нескольких условий и получения текстового значения (в этом варианте дубли ключа также вносят непореденность)
— либо формула массива для высталения парамета по столбцам, а не только по строкам. Но это довольно медленно
Вот кстати, настройка на корпоративный Exchange может утомить. В самом аутлуке два поля — адрес сервера и логин. Но в связи с шифрованием могут быть нюансы — после установки сертификата адрес сервера будет не тот, какой вы думаете.
Для сравнения приложили бы настройку аутлука — там 3 клика, ввод почты/пароля и 5 сек ожидания.
И маленький такой моментик — OWA может быть выключен с большой долей вероятности на корпоративных серверах. И все эти приблуды сразу не работают.
Вы сами перечитайте свои комментарии — это даже не компромисы. Вы просто терпите! Едите кактус и терпите.
Нет встроенного календаря, нет иконки в трее, нет нормальной адресной книги или она виснет, календарь не работает или глючит. Инструкция по подключению на 10 листах!!!
К аутлуку какие претензии то после этого? У него все работает.
При выборе базы данных первый вопрос не что и как хранить, вы на него потом найдете ответ, а что вам надо с данными делать.
Если вам ничего с ними делать не надо, то и хранить их не надо. База данных не нужна.
Если вам надо посмотреть на них справа, потом сверху, потом посчитать вхождение «этого» в «то», средние, промежуточные итоги — то без SQL это очень затруднительно. Как минимум закончится изобретением миниSQL на коленке.
Если вам надо записать много данных, а потом их просто показать, целиком или кусками — то можно пробовать NoSQL. Но как только у вас появятся дополнительные требования к фильтрованию и связям — то вы постепенно начнете смотреть в сторону SQL — там уже есть ответы на многие ваши ещё не заданные вопросы.
Характерно, что сам вопрос о NoSQL встал на повестку дня когда память стала доступна гигабайтами и не надо заморачиваться быстродействием — положил базу в память и все.
Истина посредине. Для хранилища котиков подойдет NoSQL, т.к. зачастую записей будет больше, чем чтения. При этом взаимосвязи авторов котиков будут храниться в SQL, а сам SQL ещё разделится на горячие и холодные данные.
Кроме этого, NoSQL, как и другие не типизированные средства разработки, выполняет социальную функцию — легкий вход в программирование широких масс населения, оставляя вопросы типов и структур данных для тех, кто прошел идиотентест простых ответов на простейшие вопросы.
Иначе нельзя объяснить «преимущество» NoSQL — «отсутствие жесткой структуры данных». Это как же вы с данными работать будете если не знаете что там? По сути, под каждый кейс данных писать парсер и распознавать содержимое.
Так что вы скорее всего разработчик ниже среднего или зарабатываете очень мало относительно в среднем по рынку.
Раздражающие правила по паролям приходится обходить с помощью браузера, который запоминается все внесенные пароли, которые потом можно посмотреть (maxthon). А кому от этого легче? Это та же бумажка с паролем, приклеенная к монитору.
Ещё одни странные люди, сменив версию Ангулара с 1 на 2, тоже перешли на TypeScript (жесткая типизация). Наверное, им надоело есть кактус.
А вот кто реально уничтожает компании и их персонал всеми этими оценками — это хр-директора и менеджеры во всяких KPI и системах оплаты труда на их основе.
А правило Гудхарта очень быстро, за пару месяцев, выводится любым сотрудником, у которого зарплата зависит от KPI — как только ему поставлены ВАЖНЫЕ показатели, все остальные сразу становятся НЕВАЖНЫМИ. При этом общее качество работы и системы работы его не волнует — «жираф большой, ему видней».
Сам попробовал электрон, но на второй день снес — дешевле в пкстую форму приложения на дельфи7 поставить браузер на всю форму, а страницы и всё остальное зашить в ресурсы (ИЕ он и так умеет)
Дешево и сердито.
Там все тоже самое — можно сделать шаблоны для собственного тега с обработкой вложенных в свой тег дочерних элементов.
Годная вещь была, немного сложноватая на старте.
Однако, проблема таже самая, что и до сих пор — js код никак не привязан к элементам браузера и приходилось придумывать лисапеды по навешиванию событий на сгенерированный html, чтобы в итоге работать с тегом как с объектом.
Когда нибудь web components сделают переворот в разработке. Когда-нибудь. А пока 15 лет потрачены на непонятно кому нужные новые стандарты и языковую вкусовщину, которая почему перекомпилируется в древний js.
Каждая новая методика или технология воспринимается как панацея.
Но, кроме творчества и влеченности, отличетельной чертой ИТ-отрасли являлется очень узкий гругозор.
Я хочу сказать, что большинство «новых» методик и технологий имеют возраст в несколько десятков лет и 2-3 итерации забвения.
Приведу примеры «килер-фич» из смежной области, управленческого менеджента:
— «ABC-costing». 10-15 лет назад: методика управления накладными расхода. Куча книг, десятки семинаров, много проектов по внедрению. Результат — она забыта. Причина — ни одго успешного проекта внедрения.
— KPI — медодика управления предприятием с использованием «ключевых показателей». Изначально выглядела как некий dush-board предприятия — по 4-5 показателя на производство, финансы, маркетинг и персонал. За посление 15 лет доведена до абсурда — по сути превратилась во внедрение «сдельщины» по всех профессиях. Много компаний превратились в «террариум единомышленников» благодаря этому.
— «описание бизнес-процессов» — здравая в начале идея доведена до бюрократического формализма — к моменту завершания описания всех процессов и создания по ним инструкций компании может уже и не быть. Реально работает в узких отраслях и подсистемах — СМК ISO9000 и низовые процессы по исполнителям при разработке ПО.
— «бюджетирование» — старая как мир идея в очередной раз полюбилась публике 15 лет назад, когда новын бизнесмены прочитали такое в газетах (о том, что оно десятилетиями работало — они ещё не знали). Запустилось множество проектов во многих странах и компаниях. В текущий момент идея жива в кулуарах — реальные работающие системы бюджетирования не выходят дальше Экселя и конкретных людей, знающих специфику именно этой компании и её продукцтов. Ни одной общепринятой технологической платформы все ещё нет.
— «20% времени на личные проекты» — можная фишка для модной компании. Став корпорацией, Гугел как-то незаметно прикрыл лавочку.
В общем, ко всем этим «модным» технлогиям надо выждать время — года 2-3, а лучше 5. В большинстве случаев они перестаю быть модными и исчезают.
Пока ещё не опровергнута классика управления: стратегические цели — план их достижения пошагово — цели и задачи на каждом шаге — тактика по достижению локальных целей и задач.
Имеено по этому шаблону надо оценивать метолики и теории и определять их место.
Отсюда же связка Проектант — инженер — прораб — строитель, ой, CTO — продакт менеджер — проджект менеджер — разработчик.
Почти все таории, описанные выше, пытались покрыть эту цепочку частично или целиком.
Кратко по скруму — это так называемый «простой неправильный ответ на сложный вопрос».
Состоит он из смеси атомарных бизнесс-процессов, обещания счастья для неспециалистов и KPI в творческих профессиях. Уже сам набор компонентов вызывает скепсис по жизнепособности: про стратегию нет вообще ни слова, голая тактика на 2 недели с отжимом продуктивности по KPI — сомнительная на марафонской дистанции аврально-потогоная система.
Суть статьи в следующем.
Придумываем 4-хзвенную технологию.
Звено 1 — база данных
Звено 2 — сервер, которые генерит данные из базы наружу. Сейчас это можно слово «RAST»
Звено 3 — сервер, который генерит шаблон страницы в HTML с помощью js. Это костыль данной технологии — генерацию страницы уже не знаю куда приткнуть: typescript(чтобы можно было больше 3-х файлов написать коллективом более 2-х человек) + babel (потому что нужен прогресс ради прогресса без понятного результата) + framework1-2-3 (костыли для компонентной разработки, потомоу что HTML убог и примитивен). Если выйти за рамки JS, то это все всякие разные PHP/Python/CGI спокойно делают это последние 20 лет без особых заморочек.
Звено4 — браузер, который получив шаблов HTML, подгружает скрипты и страница работает.
Всяя суть статьи в том, что звенья 3 и 4 вы можете сделать в браузере. По своему желанию — или так, или так.
Только особенность технологии JS — если сделать все браузере, то он ставит современные компы на колени (напримет тотже atom за 3-4 час а рабоыт выжирает несколько Гб оперативки на паре открытых файлов по 10 кб).
Итогог, ИЗОМОРФНЫЙ = костыль JS.
Если это слово убрать, то PHP/Python/C++/Pascal + JS — тоже можно, только модные слова типа React, Angular, ES6 — проходят мимо и остается просто работа.
Кстати, судя по статьям на хабре, технология фремворков JS деградирует — ответа, на чем писать, нет даже приблизительно, есть лишь разные варианты БДСМ.
ЗЫ. Подсказываю, как и коментатор ниже — проблема в браузере как стеке технологий.
И может я че-то не понимаю… Раньше все скидывали на клиент, чтобы сервер меньше считал. А теперь типа все назад на сервер, потмоу что ОДИН клиент не тянет. А сервер значит 1000 клиентов — легко.
И вот что ещё странно. На клиенте утечка памяти есть, а на сервере на 1000 подключений на томже самом стеке технологий не будет… Странно.
А как дебажить эти ваши изоморфные приложения???
Вопрос 1. Консультанты. Феномен консультантов вызван неколькими факторами:
а) крайне низкий уровень понимания теории и практики управления и экономики собственников бизнеса и топ-менеджеров в среднем и особенно крупном бизнесе. Как ни странно это звучит. У кого-то бизнес вдруг удался, не смотря на персоналии, кто-то залез в кресло босса нетрудовыми успехами. В таких случаях людям льстит, что человек знающий много умных слов и имеющий корочку МБА, находится в позиции подчиненного и более того — заискивающего, т.к. надо убедить подписать контракт и поэтому консультанты рассказывать будут что угодно и обещать тоже.
б) с помощью консультантов топ-менеджмент или собвенники хотят продвинуть какую-то свою идею и подвинуть или перетряхнуть подчиненных или параллельные службы
в) это модно. Дорогим галстуком или машиной уже не удивить. А вот типа пригласить консультантов — это да, это типа мы такие продвинутые и типа развиваем бизнес до заоблачных высот.
Вопрос 2. Почему консультанты довольно часть — вред. Сюда же запишет и разных внедренчев — вред одинаковый.
а) в статье уже сказано — это бывают люди, торгующие лицом, которые не могут принести пользу как работники. Практикуется «чайка-менеджмент».
б) консультанты давят авторитетом, не учитывают требования заказчика, потому что считают, что они умнее — в итоге разламывают то что есть, а новое собрать способностей не хватает.
в) продукт или методика, которые внедряются — слишком тяжело настраивать или требует много знаний и труда. И поэтому начинают впихивать стандартные методики — все что в них не влазит — выкидывается
Вопрос 3. А необходим ли КПИ?
Тут надо понимать такие вещи:
а) норма управляемости. Это 5-7 человек на одного управленца. Если человек больше — надо делегировать, и приэтом надо как-то контролировать того, кому делегированы полномочия И КПИ нужен в каком-то виде.
б) когда вы не можете добросить дыроколом в каждого своего работника — тоже как-то надо понимать, что он там делает
в) надо своим умом дойти до того, что вам нужен КПИ. Собственнику и топ-менедженту надо учиться, учиться и учиться. Ситуация в статье — «книги читать некогда, но нужен КПИ» — это заранее провальный проект, никакое ПО его не вытянет. Это как дать планшет маленькому ребенку — до определенного момента об будет успешно тыкать пальцен, но рано или поздно будет озадачен непониманием.
г) в малом бизнесе КПИ очень простой — наличие живых денег у соственника. Если денег нет — надо срочно предпринимать корректирующие действия.
д) в среднем бизнесе необходимоть КПИ определяется 2 факторами: пониманием что это такое и как работает и узкой специализацией людей, к которым применяется КПИ.
Вопрос 4. Какой вред от КПИ?
КПИ работает только тогда, когда функции четко поделены и они однообразны для каждого человека.
Сама суть «ключевые показатели», за которые вы платите деньги — автоматически переводит все остальные показатели в «неключевые». Не надо считать своих работников глупыми, они очень быстро приспособятся.
Отсюда проблема со сдельно работой — страдает качество
Отсюда пролблема с процентом от продаж — может упасть маржа и прибыль
Надо четко понять, что именно будет «ключевым », а чем люди будут пренебрегать
И именно поэтому любое совмещение одним человеком 2-3-4 функции запрещает применение КПИ — вы угробите и работу и человека.
Это хорошо, что сделали типа ВПР, но через ПОИСКПОЗ, хотя в первоначальной статье именно про это в коментариях и говорилось.
Однако…
Функции пита ВПР или ПОИСКПОЗ прменяются в 2-х видах задач:
1. Разовая обработка больших массивов данных в экселе. Как оказала практика, если вы через ОЛЕ выгружаете данные эксель, то лучше выгружать сразу в Аксес. Для статитстической обработки очень больших данных это намного практичнее и быстрее.
Более того, если выгружать в эксель и обрабатывать в нем, то нюансы функции ВПР не так важны, как и скорость — работа разовая, можно 1- сек подождать.
2. Рабочие файлы, в которых ежедневно, ежеднелельно и ежемесячно ведется работа, обрабатываемые данные могут заносится туда выгрузками или вручную (т.е. никаких сортировок).
И функции типа ВПР, ПОИСПОЗ или СУММПРОИЗВ применяются в массовых масштабах для создания реляционной базы.
Данные измеряются не 200 тыс строк, а на порядок меньше, зато указанные функции используются по 5-15 раз в каждой строке, итого они вызываются под 1 млн раз.
Это я к чему? При такое количестве вызоов функций любое использование ВБА подвешивает программу на минуты и часы. По этой простой причине примеются исключительно встроенные фукнции, т.к. скрипты катасрофически тормознутые.
Если у вас 100 вызовов ВБА — это нормально, если 100 тыс. — это беда.
Причем тормозит именно сам механизм ВБа, даже если вы там внутри вызываете встроенные функции.
Также он проигрывает ещё в критичной зависимости к структуре данных. Добавление одного столбца в таблицу данных может все поломать.
Кстати, в стетьях, на которые ссылается автор, сравниваются в том числе и ВПР и ИНДЕКС+ПОИСКПОЗ. Вторая связка произрывает на 5-10% (на данных в 200 тыс строк 50 сек вместо 45), что не критично, зато поддерживает целостность данных.
Это понятно. Но тут ведь описывается вундервафля с ускорением в 25 раз. Только кто-то должен не забыть отсортировать данные. Для разовой обработки набора данных — пойдет. Для рабочего файла, которые используется регулярно, да ещё и несколькими пользователями — это выстрел в ногу. Такойже как сводные таблицы.
Кстати, ни автор статьи, ни в тех статья, на которые он ссылается, не указывается, за сколько с задачей справится сводная таблица — это может быть самый простой путь для разовой обработки данных.
Вообще, для разработки именно приложений многократного использования пока лучше всего показывают себя СУММПРОИЗВ (быстрее, но требуют данных одинакового размера) и формулы массивов (они медленне, но позволяют разноразмерные данные) в связке с таблицам (именование области данных с именованными столбцами)
Например, 3 столбца отбора, 1 столбец данных. Добавляем 5-й столбец, который соединяет значения этих 3-х столбцов отбора: = СЦЕПИТЬ(Столбец1;"-"; Столбец2;"-"; Столбец3)
Потом при поиске пишем =Индекс(Столбец4; ПОИСКПОЗ(СЦЕПИТЬ(Условие1;"-"; Условие2;"-"; Условие3); Столбец5;0))
— ключ в первом столбце
— ключ сортированный по возврастанию
— повторый ключа вносят неопределенность
Для составления чего-то, похожего на реляционную базу с контролем ошибок неприменима.
Поэтому
— либо СУММПРОИЗВ — для работы с числовыми результирующими столбами и отбор по любому количеству параметров
— либо связка ПОИСКПОЗ+СЦЕПИТЬ+ИНДЕКС — для опятьже нескольких условий и получения текстового значения (в этом варианте дубли ключа также вносят непореденность)
— либо формула массива для высталения парамета по столбцам, а не только по строкам. Но это довольно медленно