Потому что в заголовке "может одобрить", а в статье сразу - "точно не одобрит", а в оригинальном источнике про одобрение вообще нет ни слова. Ну, как по мне. это из разряда "Почему теперь говорят «отрицательный рост» вместо падения"
Есть противоречие, так как комментатор выше говорит об убытках, тогда как "деньги не пахнут" применяется в плане получения прибыли. А так, разговор про деньги, несомненно. Как если бы вас посадили, то все свелось бы лишь к тому, что у вашей семьи стало меньше денег и все, верно? )
Самым очевидным плюсом унитарного патрона стало увеличение скорострельности оружия – уже не приходилось совершать кучу операций, как с дульнозарядным оружием. Закинул патрон, закрыл затвор – и стреляй. Потом к оружию начали массово приделывать магазины, ну а затем и вовсе обленились, переложив функцию передёргивания затвора на энергию пороховых газов.
Как бы я не любил командную строку, думаю, при детальном рассмотрении становится очевидным, почему перспективы у такого подхода нет. Суть командной строки - один из множества вариантов взаимодействия компьютера и человека. Любой интерфейс требует от человека навыков работы с ним. Интуитивно понятный интерфейс требует меньше времени на изучение навыков работы с ним. В этом плане командная строка проигрыает любому визуальному интерфейсу. Вы говорите - существует куча репозиториев с утилитами. ОК. Сколько усилий необходимо затратить что бы найти их? :) Разобраться что там, установить, изучить параметры и начать эффективно использовать?
Я понимаю вашу позицию в целом, однако считаю, что ваше стремление показать прелести командной строки сродни попытке убедить людей массово пересесть на лошадей, потому как у них проходимость выше и ресурсов почти не требуют и т.д. Да, определенно найдутся единицы энтузиастов, разделяющих ваше стремление на Дикий Запад, но нужно хорошо понимать, что основная задача производимых инструментов - скрывать сложность, абстрагировать пользователя от этой самой сложности. И на этом пути консольные утилиты проиграют. Или, скорее, уже проиграли.
Вангую что где-то или уже существует или вот-вот появится визуальный интерфейс для компоновки пайпов из консальных утилит. В котором существует группировка утилит по сути выполняемых задач, параметры сразу показыаются пользователю с возможностью выбора предустановленных значений и т.д. И этот инструмент будет делать две важных вещи: все еще предоставлять гибкость, к которой вы так аппелируете и, второе, скрывать от пользователя сложность (а именно необходимость помнить названия, параметры и значения парамеров каждой из тысячи утилит)
И, возможно, этот интструмент тут же заменит масштабная система конекстного поиска, которая по запросу будет сама компоновать пайп, абстрагируя даже необходимость искать конкрктные утилиты внутри группирования.
Но, коннчно же, среди огромной массы людей всегда найдется пара энтузиастов, утверждающих что наличие токарного станка в гараже, дающего гибкие возможности производства цилиндров для вашего авто, это путь к процветанию и познанию дзена. И будет правы. По-своему :)
Если вам важна история переписки, то в чат можно добавить бота для сохранения всей истории. Будет честно по отношению ко всем :) как декларация того, что «внимание, история этого чата записывается».
Спасибо что подделились, но, по факту, у вас не было микросервисной архитектуры. Вы ее неправильно поняли. Делить нужно было по ролям, сделать возможность масштабирования конретной роли и вся ваша боль ушла бы. Вы же раскидали по разным воркерам код и назвали это микросервисной архитектурой. От неправильного ее формирования вы и получили проблемы и с саппортом и вот эти
Дополнительная проблема заключается в том, что каждый сервис испытывает разную нагрузку. Некоторые сервисы обрабатывали несколько событий в день, а другие – тысячи в секунду.
Вообще-то, есть довольно давно бот, написанный хабражителем shpaker. Пользуюсь больше года уже, наверное. Собственно, на эту статью из него перешел ) см. tmfeed
Осталось дождаться критического количества тру-программеров, которые создадут такой мета-язык, в котором вообще не надо никакого кода писать. Чистая алгоритмика. Ну почти как Wolfram, наверное… Что бы людям остался только творческий процесс. Ну, знаете, как в цивилизациях, где все роботизировано и автоматизировано. А то лямбды и дженерики — это неспортивно:))
Вместо копирования-вставки можно использовать Ctrl+D (В маке, видимо, CMD + D). Ну и не согласен с комментаторами насчет детсада. Хоткеи, конечно, можно и нужно изучить, но всегда можно «провтыкать» что-то или не оценить каких-то возможностей. Люди для того и делятся информацией, что она кому-то может оказаться полезной. Если она кому-то очевидна, то это не значит, что она не нужна кому-то другому. Считать, иначе и есть как раз детсад и инфантилизм в чистом его проявлении. Никто же не мешает увидеть, что информация для читающего неактуальна и просто закрыть статью верно? :)
А не-менеджеры будут использовть тоже самое подключение к глобальным знаниям, что бы противостоять этому. Когда у всех есть доступ к такому ресурсу — проблемы, которую Вы описываете, не будет существовать.
У вас спискок типов переменных на самом деле — список примитивных типов. И в примерах только примитивные типы используются (ну и один раз функция). А ведь вся соль дженериков и типизации проявляется, когда в качестве типа используется класс.
Есть вариант и без скрытия импортов: www.npmjs.com/package/packagerify
Из бонусов: автокомплит в Идее (ну и ВебШторме, разумеется) и возможность пробежаться в цикле по модулям в пакете (удобно при создании разных загрузчиков)
Ну по поводу подвигаем ввехр-вниз — я тут не отрицал необходимости ползунка. Поискать в окрестностях как раз укладывается в какое-то небольшое количество записей, которые можно глазом и мозгом охватить, я об этом выше писал. Понять где в списке примерно находится Петров, много ли Петровых в перечне — ну я понимаю, что Вы хотели какой-то пример привести, но согласитесь, он не очень удачный) Я пока не придумал задачу, для решения которой нужен был бы глобальный скролл. В пределах 20-40 записей — запросто (любой небольшой выпадающий спискок сюда так же относится). А вот скроллить на большем количестве записей какая может быть необходимость — пока не представляю.
Но с другой стороны абсолютно с Вами согласен по поводу "психологической зацепки". А даже, скорее, привычки. Так сложилось. Кто-то придумал там в конце 60-х табличное отображение и подумал, что нужно ж просматривать таблицу, значит нужен скролл. С тех пор так оно и копируется и пользователи привыкли. И я запросто могу представить себе немолодого бухгалтера, который скроллит таблицу из нескольких тысяч записей в поисках счета по номеру. Счастлив ли пользователь при этом? Возможно. Продуктивен? Врядли :)
Я бы сравнил (не аналогия, а так, сравнение для "поулыбаться") скролл с дисковым номеронабирателем. Всем нравилось, палец засунешь в технологическое отверстие и наяриваешь диск этот, а он так трещит, когда назад крутится, красота. А, главное, — детям нравится). Пальцы иногда застревали, но удобно ж, а не нужно телефониста просить соединить вас с абонентом, все можно делать самому. И бабушки не хотели переходить на кнопочные телефоны, потому что ж неудобно и непонятно, а диск — психологическая зацепка.
Но когда номера были 5-значные, то скорость работы с диском и с кнопками была сравнима. А сейчас бы понакручивать диск для дозвона внуку на мобилку — уже и невесело как-то ).
По поводу 1С — ну они экспериментируют с интерфейсом (как некоторые с меню Пуск). Не скажу, что мне нравится их реализация (напоминает контрол из Делфы для пробегания по записям), но наличие простого поиска — это определенно шаг вперед. Хотя не знаю как он там у них реализован, может ищет только по одному полю и только 100% совпадения, не сталкивался с 1С, но можно ожидать подвоха.
В общем дополним резюме из предыдущего коммента (там я только о больших обьемах данных говорил):
Для небольших наборов записей скролл — хорошее решение. Скроллить большие обьемы данных — бессмысленная (имхо, конечно же) трата времени. Сначала минимизируем выборку фильтрацией, потом скроллим.
П.С. за ссылку спасибо, интересная работа, славно потрудились!
Ну да, 900 000 тысяч вариантов есть, но я же предлагаю взглянуть на проблему под другим углом. Суть задачи — пользователь ищет информацию. Смотрите сами, когда нужен скролл в повседневной жизни? Когда вы не знаете, что ищете или когда просто листаете ленту новостей/котиков. Тут скролл удобен, потому что вы не нацелены ни на что конкретное. А теперь давайте смотреть вариант, когда пользователь ищет что-то. Ведь что такое "поместить скролл примерно на середину"? Это значит, что пользователь примерно знает что хочет. Найти, скажем, Петрова в списке. Тогда поьзователь знает что примерно на середину скролла если ткнуть, то наверное +-200 записей попадет на Петрова. Тыцнул, видит, что петрова нету, начинает скроллить вверх-вниз в поисках. То есть, что такое "пользователь скроллит"? Это пользователь выполняет визуальную фильтрацию. Которая, мало всего прочего, еще и подводить может. Банально скроллил и не заметил нужную строчку. Получается, что пользователь использует некий алгоритм поиска, но он крайне неоптимален, так как человеку свойственно ошибаться, не замечать чего-то и так далее. Потому поиск информации с помощью скролла — неэффективный путь. Его может использовать только человек, который не знает (или не хочет знать) других способов, более удобных. Элементарная строка поиска, в которой пользователя не заставляют выбирать "по какому полю фильтровать. теперь введите значение", а в котором он просто вводит часть искомой информации и получает результат уже будет на голову выше, чем скроллинг в неизвестность )
Что касается реализации "отобразим соседние". Ну тут все просто. Что такое "соседние"? Это значит, что информация упорядочена по каким-то признакам и тогда мы можем определить соседние записи. Дальшк, если в лоб решать, простой запрос с юнионом: селект, который выбирает нужную запись + 2 селекта для предыдущих 5 и последующих 5 (order by asc/desc по признакам + top/limit 5).
В общем, много текста, резюмируем: суть в том, что пользователю не надо пиу-пиу-скролл. Пользователю нужна та информация, которую он пытается найти. Скроллинг в этом деле — плохой помощник. Поисковый запрос — хороший.
Лично мне кажется, что оптимальнее для небольших таблиц (до, скажем, 40 записей), загружать их на клиент сразу (вплоть до кеширования, если данные редко меняются). А для больших таблиц иметь возможность «переставить ползунок примерно на середину из миллиона записей» — очень сомнительное решение. Ну тоесть, я понимаю, что пользователи когда видят ползунок — хотят им покрутить, но по факту они осуществляют операцию фильтрации, только крайне неоптимальную. Удобнее было бы предоставить интерфейс, скажем так, «умной» фильтрации. Что бы при надобности — показывало и соседние записи. И выполняло нечеткий поиск (в том же PostgreSQL пачка функций для этого, в отличие от некоторых мелких и мягких). А скроллить массив данных более какого-то Х (думаю, не ошибусь, если предположу, что во внимание пользователя за раз врядли уместится больше 20-40 записей) — это неэффективное использование инструмента и времени. Осталось это донести пользователям :)
Просто вы в дискуссию ввели понятие абсолюта. А абсолют — неопровержим. Соответственно, и дискуссии не получается. Нет смысла предлагать аргументы, которые разбиваются о скалу "невозможности познания".
Вся суть в этом маленьком неприметном предложении посередине статьи:
"Не нужно играть в героев, это опасно."
А также учесть, что Ventavia это не то, что бы не единственный представитель третьей стороны, а ...
Немного факт-чекинга
Потому что в заголовке "может одобрить", а в статье сразу - "точно не одобрит", а в оригинальном источнике про одобрение вообще нет ни слова. Ну, как по мне. это из разряда "Почему теперь говорят «отрицательный рост» вместо падения"
Корелляция заголовка и первых абзацев - захватывающая. Двоемысленная, я бы сказал.
Есть противоречие, так как комментатор выше говорит об убытках, тогда как "деньги не пахнут" применяется в плане получения прибыли. А так, разговор про деньги, несомненно. Как если бы вас посадили, то все свелось бы лишь к тому, что у вашей семьи стало меньше денег и все, верно? )
В качестве дополнительной иллюстрации позволю себе процитировать свежую статью про гильзы:
Как бы я не любил командную строку, думаю, при детальном рассмотрении становится очевидным, почему перспективы у такого подхода нет. Суть командной строки - один из множества вариантов взаимодействия компьютера и человека. Любой интерфейс требует от человека навыков работы с ним. Интуитивно понятный интерфейс требует меньше времени на изучение навыков работы с ним. В этом плане командная строка проигрыает любому визуальному интерфейсу. Вы говорите - существует куча репозиториев с утилитами. ОК. Сколько усилий необходимо затратить что бы найти их? :) Разобраться что там, установить, изучить параметры и начать эффективно использовать?
Я понимаю вашу позицию в целом, однако считаю, что ваше стремление показать прелести командной строки сродни попытке убедить людей массово пересесть на лошадей, потому как у них проходимость выше и ресурсов почти не требуют и т.д. Да, определенно найдутся единицы энтузиастов, разделяющих ваше стремление на Дикий Запад, но нужно хорошо понимать, что основная задача производимых инструментов - скрывать сложность, абстрагировать пользователя от этой самой сложности. И на этом пути консольные утилиты проиграют. Или, скорее, уже проиграли.
Вангую что где-то или уже существует или вот-вот появится визуальный интерфейс для компоновки пайпов из консальных утилит. В котором существует группировка утилит по сути выполняемых задач, параметры сразу показыаются пользователю с возможностью выбора предустановленных значений и т.д. И этот инструмент будет делать две важных вещи: все еще предоставлять гибкость, к которой вы так аппелируете и, второе, скрывать от пользователя сложность (а именно необходимость помнить названия, параметры и значения парамеров каждой из тысячи утилит)
И, возможно, этот интструмент тут же заменит масштабная система конекстного поиска, которая по запросу будет сама компоновать пайп, абстрагируя даже необходимость искать конкрктные утилиты внутри группирования.
Но, коннчно же, среди огромной массы людей всегда найдется пара энтузиастов, утверждающих что наличие токарного станка в гараже, дающего гибкие возможности производства цилиндров для вашего авто, это путь к процветанию и познанию дзена. И будет правы. По-своему :)
Вообще-то, есть довольно давно бот, написанный хабражителем shpaker. Пользуюсь больше года уже, наверное. Собственно, на эту статью из него перешел ) см. tmfeed
Из бонусов: автокомплит в Идее (ну и ВебШторме, разумеется) и возможность пробежаться в цикле по модулям в пакете (удобно при создании разных загрузчиков)
Но с другой стороны абсолютно с Вами согласен по поводу "психологической зацепки". А даже, скорее, привычки. Так сложилось. Кто-то придумал там в конце 60-х табличное отображение и подумал, что нужно ж просматривать таблицу, значит нужен скролл. С тех пор так оно и копируется и пользователи привыкли. И я запросто могу представить себе немолодого бухгалтера, который скроллит таблицу из нескольких тысяч записей в поисках счета по номеру. Счастлив ли пользователь при этом? Возможно. Продуктивен? Врядли :)
Я бы сравнил (не аналогия, а так, сравнение для "поулыбаться") скролл с дисковым номеронабирателем. Всем нравилось, палец засунешь в технологическое отверстие и наяриваешь диск этот, а он так трещит, когда назад крутится, красота. А, главное, — детям нравится). Пальцы иногда застревали, но удобно ж, а не нужно телефониста просить соединить вас с абонентом, все можно делать самому. И бабушки не хотели переходить на кнопочные телефоны, потому что ж неудобно и непонятно, а диск — психологическая зацепка.
Но когда номера были 5-значные, то скорость работы с диском и с кнопками была сравнима. А сейчас бы понакручивать диск для дозвона внуку на мобилку — уже и невесело как-то ).
По поводу 1С — ну они экспериментируют с интерфейсом (как некоторые с меню Пуск). Не скажу, что мне нравится их реализация (напоминает контрол из Делфы для пробегания по записям), но наличие простого поиска — это определенно шаг вперед. Хотя не знаю как он там у них реализован, может ищет только по одному полю и только 100% совпадения, не сталкивался с 1С, но можно ожидать подвоха.
В общем дополним резюме из предыдущего коммента (там я только о больших обьемах данных говорил):
Для небольших наборов записей скролл — хорошее решение. Скроллить большие обьемы данных — бессмысленная (имхо, конечно же) трата времени. Сначала минимизируем выборку фильтрацией, потом скроллим.
П.С. за ссылку спасибо, интересная работа, славно потрудились!
Что касается реализации "отобразим соседние". Ну тут все просто. Что такое "соседние"? Это значит, что информация упорядочена по каким-то признакам и тогда мы можем определить соседние записи. Дальшк, если в лоб решать, простой запрос с юнионом: селект, который выбирает нужную запись + 2 селекта для предыдущих 5 и последующих 5 (order by asc/desc по признакам + top/limit 5).
В общем, много текста, резюмируем: суть в том, что пользователю не надо пиу-пиу-скролл. Пользователю нужна та информация, которую он пытается найти. Скроллинг в этом деле — плохой помощник. Поисковый запрос — хороший.
Так же рекомендую ознакомиться с этим материалом: http://lesswrong.ru/w/%D0%92%D0%B5%D1%80%D0%B0_%D0%B2_%D1%83%D0%B1%D0%B5%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F
Просто вы в дискуссию ввели понятие абсолюта. А абсолют — неопровержим. Соответственно, и дискуссии не получается. Нет смысла предлагать аргументы, которые разбиваются о скалу "невозможности познания".