Много повидал похожих проблем, но апофеозом стал недавний случай, когда человек пытался войти в мобильное приложение для сотрудников. Диалог был примерно такой:
-приложение требует пароль!
-используйте тот же, что и для настольного компьютера
-не могу, на телефоне не получается нажать shift+F5
Спасибо за статью - хорошо написано, и даёт представление о процессе именно вашего вникания. От себя добавлю, что главная проблема дарта - малое количество готовых библиотек, но они здорово растут в количестве и качестве, вангую, что скоро этой проблемы не будет
Пара вопросов: 1) какая самая неожиданная вещь была для вас во флаттере? что-то вроде "шоооо, зачем именно так?!" 2) приходилось ли руками подправлять код js после билда веб-версии? (Мне - регулярно приходится, что б работал скролл внутри фрейма) 3) как вы обходите то, что при импорте html библиотеки не билдится моб версия? (Мой рабочий вариант - комментирование импорта, так как условный импорт не спас совсем) 4) попробуйте не поднимать каждый раз новый стек роутов, так как по кнопке "назад" я возвращаюсь в пред экран, хотя он по идее уже не должен быть доступен. Или так и задумывалось? 5) setState и streamBuilder хватает для большинства задач, особенно при нормальной доке, те камрады, что говорят про setState и "перерисовку всего" не учли логику рендера флаттера или злоупотребляют ключами виджетов. Конечно уже на крупных проектах нужно что-то просто заставляющее технически всех писать в схожем стиле. 6) а где брали дизайн для карточек? 7) андроид тоже можно билдить в докере
Может это конечно из-за восприятия текста, но пока ваш комментарий воспринимается как "ох уж эти тестировщики - достаточно смелые что б баги в интерфейсе находить, вот попробовали б они жалобы клиентов обрабатывать - посмотрели б на них!"
Муницпальная полиция - это безоружные люди, которые не обязаны бороться с криминалом, для этого есть просто полиция. И если муниципальщики смогли хорошо выполнить свою функцию "уменьшить затраты города на ликвидацию последствий вандализма", то они ж молодцы.
Ну и активистов я там в этом процессе вообще не помню.
Яркая аналогия тому, что происходит просто. Тяжело найти файл в неструктрированном хранилище (как винт с биткоинами на помойке)
Если имеешь доступ к таком хранилищу, то имеешь доступ ко всем элементам внутри него (зашёл на помойку, и нашёл что помидор гнилой, что кольцо с бриллиантом)
Оно разрастается, а просто "сжигать нельзя", а размер то - ограничен
Ну много аналогий можно поискать, а если коротко, то просто на ум приходит когда такое видишь
На своём примере (работа в большом банке с тысячами сервисов):
1) проблема перекладывания ответственности решается чётко выраженными соглашениями о сервисе (SLA)
2) в условиях современной разработки сегодня тебе говорят, что это временный сервис, написанный под конкретную задачу, завтра это боевой сервис, который «должен пожить годик», послезавтра используется в десятках процессов. И в условиях микросервисной архитектуры намного удобнее править и оптимизировать то, что теперь приходится поддерживать.
3) преимущество микросервисов ещё в том, что из них можно очень быстро собирать разные бизнес-процессы так как ты просто говоришь владельцам сервиса — «С завтрашнего дня я буду давать Вам нагрузку 50 запросов в секунду, ок?» и всё, тебя не волнует ни оверсайзинг дисков сервера, который они юзают, ни количество шардов — ничего не волнует, заключил SL и вперёд — настраивать логику.
4) небольшой модифай моего 3го пункта — сборка сложных процессов за мизер времени, когда есть готовый винегрет сервисов представьте что Вам надо сделать процесс, который обслужит банально одно событие или должен поработать пару часов, но сложный, с разветвлённой логикой и кучей функционала. Либо писать монолит с кучей всего, либо забабахал процесс на корезоиде, который пару раз вызвал каждый сервис и всё — никогда больше туда не вернётся. Зато деньги в кармане и клиент доволен.
И относительно темы статьи несколько соображений:
1) читать отзывы о преподавателях на профильных сайтах
2) если есть видеозаписи лекций — вообще профит
Общая концепция возражений не вызывает, но утверждение "Для этого лучше всего подходит XML" ничем не обосновано. Правильнее было бы сказать "В рамках нашего стека технологий лучше всего подошёл XML" иначе это выглядит как "Слово "молоко" лучше всего говорить на испанском языке :)"
Например у нас аналогичная ситуация с кучей служб такси работает в JSON формате, и если вдруг кто-то захочет XML, то не меняя всей архитектуры просто добавим, что для этой службы нужно делать хттп вызовы в XML.
Ребята, серьёзно? Крайне редко отношусь критично к чужим статьям, так как понимаю какой труд порой может скрываться за парой строчек, но сейчас прям задели. Целая статья про один опрос?! :(
В ПриватБанке в год проводится более тысячи разных опросов сотрудников. Про клиентов вообще молчу.
Ну а если конкретно про ваш случай, то что б опрос был анонимный не обязательно не записывать данные ответившего. Достаточно честно предупредить, что данные будут обрабатываться в обобщенном виде.
Спрашивать можно по любой шкале, лишь бы можно было поделить людей на три группы:
промоутеры, те кому нравится предмет оценки
нейтралы
детракторы, те, кто будет ходить и ругать предмет оценки.
Из всего этого выводится индекс лояльности уже. Рекомендую к прочтению книгу "Искренняя лояльность. Ключ к завоеванию клиентов на всю жизнь"
Мне на эту тему ещё всегда Node-RED вспоминается — штука в принципе для драйверов умного дома, но при этом веб-приложения на ней собираются вообще непринужденно. А всё потому, что в основе Node js
Мои соболезнования =( держитесь там.
У нас не так, к счастью. Может из-за того, что короткая вертикаль власти. От CEO до какого-нибудь инкассатора максимум 5 ступеней.
Получается, что мой руководитель мне всегда ответит, потому что пишу по задачам, которые он мне и ставит. Его руководителю я не пишу ибо субординация.
Если пишу руководителям других подразделений, то не получив ответа просто пересылаю письмо с копией на его руководителя. Обычно одной переадресации хватает.
Много повидал похожих проблем, но апофеозом стал недавний случай, когда человек пытался войти в мобильное приложение для сотрудников. Диалог был примерно такой:
-приложение требует пароль!
-используйте тот же, что и для настольного компьютера
-не могу, на телефоне не получается нажать shift+F5
Мы помогли конечно, но просто кульминация :)
Спасибо за статью - хорошо написано, и даёт представление о процессе именно вашего вникания.
От себя добавлю, что главная проблема дарта - малое количество готовых библиотек, но они здорово растут в количестве и качестве, вангую, что скоро этой проблемы не будет
Пара вопросов:
1) какая самая неожиданная вещь была для вас во флаттере? что-то вроде "шоооо, зачем именно так?!"
2) приходилось ли руками подправлять код js после билда веб-версии? (Мне - регулярно приходится, что б работал скролл внутри фрейма)
3) как вы обходите то, что при импорте html библиотеки не билдится моб версия? (Мой рабочий вариант - комментирование импорта, так как условный импорт не спас совсем)
4) попробуйте не поднимать каждый раз новый стек роутов, так как по кнопке "назад" я возвращаюсь в пред экран, хотя он по идее уже не должен быть доступен. Или так и задумывалось?
5) setState и streamBuilder хватает для большинства задач, особенно при нормальной доке, те камрады, что говорят про setState и "перерисовку всего" не учли логику рендера флаттера или злоупотребляют ключами виджетов. Конечно уже на крупных проектах нужно что-то просто заставляющее технически всех писать в схожем стиле.
6) а где брали дизайн для карточек?
7) андроид тоже можно билдить в докере
Может это конечно из-за восприятия текста, но пока ваш комментарий воспринимается как "ох уж эти тестировщики - достаточно смелые что б баги в интерфейсе находить, вот попробовали б они жалобы клиентов обрабатывать - посмотрели б на них!"
Муницпальная полиция - это безоружные люди, которые не обязаны бороться с криминалом, для этого есть просто полиция. И если муниципальщики смогли хорошо выполнить свою функцию "уменьшить затраты города на ликвидацию последствий вандализма", то они ж молодцы.
Ну и активистов я там в этом процессе вообще не помню.
Насколько я помню - его искала и нашла муниципальная полиция (вохр для городского имущества).
А наркоторговцы - это всё таки вотчина криминального розыска.
Ну и да - этих объявления было ооооочень много, был резон найти пакостника и наказать в качестве примера
Прекрасно помню момент, когда решил не писать на Хабр, несмотря на все нежные чувства.
Накидал статью про Corezoid (никак с этой компанией не связан), тогда ещё мало кто о нём знал.
Получил забраковку от НЛО без единого комментария о том, где проблема.
Выдохнул и решил, что переживу.
Если теперь модераторы дают обратную связь когда не проходит материал - это просто чудесно!
P.S. А используются какие-то автоматизации анализа текста всё таки в помощь модератору (вычисление индекса простоты, подсчёт стоп-слов и т.д.)?
Яркая аналогия тому, что происходит просто.
Тяжело найти файл в неструктрированном хранилище (как винт с биткоинами на помойке)
Если имеешь доступ к таком хранилищу, то имеешь доступ ко всем элементам внутри него (зашёл на помойку, и нашёл что помидор гнилой, что кольцо с бриллиантом)
Оно разрастается, а просто "сжигать нельзя", а размер то - ограничен
Ну много аналогий можно поискать, а если коротко, то просто на ум приходит когда такое видишь
Если давать доступ на конкретную папку с конкретным файлом, то норм же ж. Не?
Уходит момент "помойки"
Думаю имеется в виду, что отдел А владеет папкой 1, а отдел Б папкой 2.
И когда нужен общий файл обоим отделам, то выкладывается в одну из папок+ даётся доступ другому конкретному человеку.
В таком варианте тот отдел, что выкладывал файл точно знает, когда его удалить.
С автоматически генерируемыми файлами примерно так же. Главное, что б область принятия решений сузилась до меньшего количества лиц чем "вся компания"
Главный вопрос - выход только веб или планируется под мобильную разработку, например под flutter?
Ну и мелкий вопрос - под Vue.js экспорт планируете?
Когда дожил до будущего.
Интересно — кодить в таком устройстве прикольно? Например вывести себе на стены несколько мониторов. Сидишь, пялишься в стену и кодишь
1) проблема перекладывания ответственности решается чётко выраженными соглашениями о сервисе (SLA)
2) в условиях современной разработки сегодня тебе говорят, что это временный сервис, написанный под конкретную задачу, завтра это боевой сервис, который «должен пожить годик», послезавтра используется в десятках процессов. И в условиях микросервисной архитектуры намного удобнее править и оптимизировать то, что теперь приходится поддерживать.
3) преимущество микросервисов ещё в том, что из них можно очень быстро собирать разные бизнес-процессы так как ты просто говоришь владельцам сервиса — «С завтрашнего дня я буду давать Вам нагрузку 50 запросов в секунду, ок?» и всё, тебя не волнует ни оверсайзинг дисков сервера, который они юзают, ни количество шардов — ничего не волнует, заключил SL и вперёд — настраивать логику.
4) небольшой модифай моего 3го пункта — сборка сложных процессов за мизер времени, когда есть готовый винегрет сервисов представьте что Вам надо сделать процесс, который обслужит банально одно событие или должен поработать пару часов, но сложный, с разветвлённой логикой и кучей функционала. Либо писать монолит с кучей всего, либо забабахал процесс на корезоиде, который пару раз вызвал каждый сервис и всё — никогда больше туда не вернётся. Зато деньги в кармане и клиент доволен.
Пролог используется в банковских системах некоторых для оценки рисков. У нас даже менеджеры для него правила писали. Но конечно мозг ломает.
Автор не засветил ВУЗ, а зря. Можно было бы предметно обсуждать.
Как раз в КПИ неплохо ж учат, и актуальным технологиям тоже. Например Flutter не так давно в проде используется, а там уже учат.
Пруф https://www.youtube.com/playlist?list=PLB3Q3FfzbFkTM9WirwrkuE4I-6zBzjg8U
И относительно темы статьи несколько соображений:
1) читать отзывы о преподавателях на профильных сайтах
2) если есть видеозаписи лекций — вообще профит
Общая концепция возражений не вызывает, но утверждение "Для этого лучше всего подходит XML" ничем не обосновано. Правильнее было бы сказать "В рамках нашего стека технологий лучше всего подошёл XML" иначе это выглядит как "Слово "молоко" лучше всего говорить на испанском языке :)"
Например у нас аналогичная ситуация с кучей служб такси работает в JSON формате, и если вдруг кто-то захочет XML, то не меняя всей архитектуры просто добавим, что для этой службы нужно делать хттп вызовы в XML.
Ребята, серьёзно? Крайне редко отношусь критично к чужим статьям, так как понимаю какой труд порой может скрываться за парой строчек, но сейчас прям задели. Целая статья про один опрос?! :(
В ПриватБанке в год проводится более тысячи разных опросов сотрудников. Про клиентов вообще молчу.
Ну а если конкретно про ваш случай, то что б опрос был анонимный не обязательно не записывать данные ответившего. Достаточно честно предупредить, что данные будут обрабатываться в обобщенном виде.
Спрашивать можно по любой шкале, лишь бы можно было поделить людей на три группы:
Из всего этого выводится индекс лояльности уже. Рекомендую к прочтению книгу "Искренняя лояльность. Ключ к завоеванию клиентов на всю жизнь"
Мне на эту тему ещё всегда Node-RED вспоминается — штука в принципе для драйверов умного дома, но при этом веб-приложения на ней собираются вообще непринужденно. А всё потому, что в основе Node js
А в обратную сторону SQL-запросы он нормально по узлам раскидывает?
З.Ы. под спойлером пример визуального программирования в вебе — мойлюбимыйкорезоид
Жаль, что закрыли Москомприватбанк.
У нас не так, к счастью. Может из-за того, что короткая вертикаль власти. От CEO до какого-нибудь инкассатора максимум 5 ступеней.
Получается, что мой руководитель мне всегда ответит, потому что пишу по задачам, которые он мне и ставит. Его руководителю я не пишу ибо субординация.
Если пишу руководителям других подразделений, то не получив ответа просто пересылаю письмо с копией на его руководителя. Обычно одной переадресации хватает.