Как стать автором
Обновить
4
0

Пользователь

Отправить сообщение
А мне пришлось поработать программистом, а потом средним звеном между саппортом (т.е. решал проблемы пользователей, которые не могли быть исправлены саппортом) и командой разработчиков (у меня были задачи для добавления нового функционала, но 60-70% времени я тратил на разгребание проблем юзеров). Компания была стандартной «галерой», но команда в которой я работал была «продуктовой», т.к. работала над одним и тем-же продуктом с начала его разработки.

Работая «изнутри», я понял что куча проблем юзеров — однотипные, но «тривиального» решения, которое можно передать в саппорт, не существует. Решения чтоб устранить целые классы проблем пользователей часто предлагались заказчику. Что-то принималось, что-то откладывалось до лучших времен. Понятно, что при выводе нового продукта на рынок (ака «Стартап»), важно зарабатывать, а баги исправить когда будет финансовая «подушка». И современный разработчик это понимает, принимает и способствует. Но когда проект живёт в таком цикле 5+ лет, то технический долг становиться неразгребаемым.

Поэтому когда Вы говорите, что пользователям нужна «поддержка продукта», то в итоге это приводит к тому, что разработчик занимается не своей прямой работой, а исправлением лажи из-за не правильной… скажем, архитектуры. И не нужно сейчас говорить про то что «архитектура» плохая. Она была заложена Х лет назад с ТЕМИ требованиями, более того, некоторые хорошие идеи были «отложены», т.к. новая кнопочка «нужна сейчас», а как оно работает пользователю\заказчику не важно. Но время никогда не выделялось на доделывание.

В итоге это приводит к тому, что куча ресурсов тратиться на саппорт, эффективность и скорость добавления новых сущностей замедляется, продуктивность и мотивация падает (ну не будет нормальный разработчик в 100-й раз писать скрипт чтоб вычистить юзер-данные).

А еще, когда разработчик предлагает «простое» и «advanced» решение проблемы, часто «advanced» продиктовано личным опытом: всё это он уже проходил на другом проекте\в другой компании и знает, что после этой кнопочки нужно будет ещё 3, которые чуть-чуть отличаются, но чтоб их добавить «потом», нужно будет с нуля переписать самую первую\простую.
Посмотрел доклад, спасибо, было познавательно. Я абсолютно согласен с тем что при возможности на уровень БД нужно выносить (а лучше дублировать) часть валидации и необходимой логики. С другой стороны — мне не приходилось работать с кодом, который бы адекватно транслировал ошибки проверок при манипуировании строками в БД. Но конкретно с JSON… Даже если брать пример докладчика: «пришёл менеджер и сказал что ему нужен доступ к базе данные пофиксить (грубо PHPMyAdmin)», то ему же с JSON придёться бороться? Хотя мне никогда не приходилось работать с системами в которых несколько приложения работают с одной БД (обычно разный UI, но Бекенд\API\DataModel+validation общий)…
Спасибо, обязательно почитаю.
«по полочкам разложилось» — но в нормальном коде обычно так-же происходит. Т.е. в приведенном в статье примере вы задаёте «маппинг» json->column на SQL, в Java->Spring->Jackson будет DTO класс с аннотациями, который пишеться в базу\отдельные колонки. Конечно если искать по JSON дереву стандартным StreamAPI будет не очень красиво, но есть приличные библиотеки.
Спасибо. «Произвольные структуры данных» — Вы имеете в виду случаи когда JSON содержит «мусорную» информацию (лишние\случайные ноды)? Ведь если «meal» находиться в разных уровнях вложенности — ничего найдено не будет? Из приведенного примера — я всё-равно пишу путь к интересующему участку… И если брать любую библиотеку для работы с JSON — всё будет примерно также. Хотя в большинстве случаев там будет последовательный перебор массивов (кажется, на Java была либа которая удачно распараллеливала поиск по XPath->XML). Хотя, наверное, на уровне БД должны использовать более «умные» методы поиска?
Не могли бы Вы дать ссылку на статью в которой хотя-бы базово и на пальцах рассматриваются преимущества хранения\использования JSON в БД вместо того чтоб распарсить его в коде приложения? Может я не там смотрю (или нужно попробовать DuckDuckGo), но гугл выдаёт статьи о том как использовать JSON, но не могу найти конретики о выхлопе такого подхода.
Интересуюсь на будущее, т.к. текущий проект на древнейшей DB2, с которой нужно спрыгивать.
Буду дома — постараюсь сделать пару скриншотов и объяснить что я имею в виду. На работе харбрасторедж заблокирован…
Мне тоже кажется что либо всё время был один бустер на обоих картинках, либо в какой-то момент СТАЛА одна картинка. Хорошо заметно в момент посадки: обе картинки показывают что оба бустера садяться на одну площадку, что не реально… Ну т.е. я бы ещё понял если-бы фон земли был перевёрнут, но я этого также не заметил…
Ориентация по звездам и солнцу очень (даже не так, ОЧЕНЬ) отличается как минимум из-за их угловых размеров и светимости, не говоря о других особенностях. Глупый троллинг вышел…
По себе заметил, что иногда экспромт лучше, чем длительная подготовка. Сколько раз не пытался написать статью или завести блог — всегда всё идёт по одному сценарию: пишу первую версию текста, которая содержит обилие отступлений и объяснений, на первый взгляд не важных подробностей, и странных речевых\письменных оборотов (ну так работает моя голова: при разговоре с друзьями, которые знают меня много лет, нужно повторять туже фразу по 3 раза, пока она не выстроиться в логически завершенное предложение). Зато она живая. При первой вычитке исправляются очевидные ляпы. При второй (обычно другой человек) — упрощаются обороты, чтоб текст стал понятным. А потом начинается самобичевание: это не относиться к теме; это моё личное суждение; тут я включил режим кЭпа и т.д. В итоге текст превращается в «инструкцию по эксплуатации», прям как в универе дипломную учили писать. Такое нудно читать…
Вы ещё не учитываете специфику рынка\культуру обслуживания. В СА на кассе (да и не только), приняты т.н. small talk — обмен любезностями, разговор не о чём. Даже если кассир говорит во время «сканнирования» это отбирает время и внимание, но в 80% случаев, если покупатель местный житель, то такой разговор ещё может затянуться. Ну а 2 лотка тоже не панацея. Обычно такие ставят в тех магазинах, где кассир сам не собирает вам пакеты и это ещё хуже, потому что люди начинают прямо на месте сортировать свои товары. Если кассир достаточно проворный, то оба лотка будут содержать товары от 2-х разных покупателей. А дальше — опять культура покупателей. Меня так зачастую зажимают в средине (покупатель впереди даже не пытается выйти из пространства между касс).
Когда удалялся из ВК (3 года назад) тоже решил выкачать все песни. Тогда написал JS скрипт, который работал только в FF (т.к. использовал какой-то API доступный только там). Ссылки доставал прямо из HTML и парсил там-же на месте. Единственная проблема — нельзя самому задавать имена файлам, но это оказалось не проблемой т.к. 90% файлов имели имя альбома-название трека и т.п. зашитыми внутрь… С тех пор не проверял изменилось VK API или нет…
Поздновато я решил отписаться, но может кто-то увидит… Как робопылесосы справляются к carpet«ами… Давно хочу купить робопылесос, но меня останавливает то что я обычным пылесосом с „турбо щёткой“ не всегда в зимний период с первого раза могу всё отчистить…

Хотелось бы добавить уточнение к формуле и светодиодам как косинусным излучателям. Так вот диаграмма направленности косинусного излучателя может описываться формулой косинуса в Н степени. Это вносит определенную погрешность в теоретическую формулу. На сколько я помню по своей дипломной работе, подавляющее большинство диаграмм направленности светодиодов из даташитов в приближении показывают косинус 3 или 5 степени

Я с таким-же столкнулся когда покупал несколько лет назад свой Nokia Lumia 520/521. Везьде его продавали именно 520 модели, но у моего оператора частоты «не стандартные» на местном рынке. Поэтому для него и подобных сделали версию 521, в которой набор поддерживаемых частот расширен по сравнению с 520. И корпус тоже длиннее на 4-5мм. Думаю, что если-бы не делали универсал (т.е. убрать некоторые частоты с 520 и добавить только то что нужно для моего оператора), то размер можно было-бы сохранить. Но в таком случае это была-бы чуть-ли не ДРМ защита
Ну давайте ещё раз займёмся холиваром (священной войной) на тему Маскау и Москвы, Лондон и Ланден и т.п. Ну и да, я не стану отрицать что в моей разговорной речи появились англицизмы, ведь мои знакомые именно так (паунд) читают сокращение «lb».
200 грамм за 0.91A$ = 1кг за 4.5A$. Вторая ссылка говорит 4.6A$ за 1кг (2паунда, что не совсем правда, т.к. 2паунда = 908 грамм)
В статье есть ссылка по которой приводятся данные за 2010-2011 год: 843$ за тонну томатов (там можно скачать PDFку).
Можете объяснить как Вы считали? У меня получается 994$ за тонну (1000кг), т.е. ~1$/1кг. А если ещё учитывать что подобную продукцию можно толкать как organic (ведь пестицидов нет), то цены (как минимум в розницу) будут выше в 1.5-2 раза.
Тут есть несколько подводных камней.
1) Я работал на проекте, которому уже больше 8 лет, на котором тестирование не автоматизировалось совсем. Там такое колличество кода и функционала, что просто написать с ноля «классическую» тестовую документацию (забить тест кейсы в какой-нить тул) займёт где-то месяцев 6 у всей QA тимы, а потом ещё месяца 3, чтоб догнать все изменения, которые были сделаны за эти пол года. Не говоря уже о покрытии всего этого тестами. Т.е. разработку нужно будет закрыть на год. Или нанять отдельную команду, которая будет только автоматизировать. Ну я таких заказчиков ещё не видел. В лучшем случае просят просто переписать всю систему с нуля и её уже покрывать тестами (как минимум «оригинал» прийдётся переделывать к тому виду чтоб он без костылей принимал Моки). Проект с нуля это другая история. А в ситуации выше без QA не знаю как обойтись. Да проект\момент упущен, но не нужно забывать, что не всегда Вам прийдётся работать над новыми системами…
2) Сейчас я работаю на проекте, в котором все тесты должны быть автоматизированны (как часть деливери). Девелоперы пишут Юнит и Интегрейшин тесты. Отдел QA — system-tests (т.е. мы не используем Моки, а пытаемся следовать юзер-кейсам). Изначально я скептически к этому относился (ну то есть авто тесты — круто, но покрыть ВСЁ это перебор), но через 3 месяца вырисовалась картина, что автоматизировать можно действительно всё. Но если на простых компонентах тесты пишутся быстро, то в тех местах где появляется средненький уровень взаимодействия с юзером, то сложность тест кода возрастает в разы. И вот тут вываливается огромная проблема.
3) Я не видел ещё программиста который по собственному желанию будет писать тесты для кода, написанного другим программистом. Можно нанять отдельного человека писать только тесты. НО! В головах работодателей до сих пор бытует мнение что QA это низкоквалифицированная работа. Соответственно ЗП на эту позицию ниже. Если есть выбор пойти в отдел QA или в отдел разработки — ответ становится очевиден. Тем кто в итоге попадает в такую команду — очень не хватает опыта. Вкладывать деньги в образование персонала — очень врятли, да и времени нет. Поэтому качество написанных тестов резко падает с увеличением сложности бизнесс логики. В итоге мне как тимлиду либо приходится переписывать тест код самому (когда уже капец времени нет), либо наперёд писать мини-фреймворк (в моём понимании это план, которому нужно следовать для тестирования похожих сценариев но с разным ожидаемым результатом), либо заставлять по 3 раза переписывать одно и тоже, т.к. колличество копипаста зашкаливает и т.п.
4) На мой взгляд возможным решением тут был-бы наём Junior«ов тестить чужой код с обещанием промоушена через год. Но тут уже появляется проблема снобства и не желанием или нехваткой времени у старших учить правильно кодить.
5) Я рад что у Вас „полный agile“, и у Вас есть возможность собрать фидбек от пользователей. Но QA очень часто приходится просить изменить UI или весь user case, т.к. логическая цепочка слишком сложная либо не очевидная. Да это проблема проектирования и документации, но именно тестирование документации тоже является частью работы QA. А потом ещё пойди докажи PM, SA и Dev, что после релиза саппорт будет завален звонками.

Ещё хотелось-бы добавить, что тестировать СВОЙ код (white box) — очень плохая практика. Не зря всегда выделяют „black box“ тестинг…
Я свои приложения всегда даю попользовать знакомым\семье. И всегда появляются упущенные сценарии либо не понимание workflow. Банально некоторые вещи слишком заумные. Для меня было шоком, когда 3 человека не смогли найти страничку favorites, которая открывалась по тапу стандартной иконки „звёздочка“.
Багтреккер это одновременно прикрытие и для девелоперов и для тестировщиков. Даже если компания только начинает путь становления, то можно использовать любой таск менеджер или на крайний случай shared online documents. Найти общий язык девелоперам и тестировщикам довольно просто, только если один из них не возомнил себя пупом мира («баг в моём божественном коде существовать просто не может» или «эта кнопка находится на 1px ниже чем я предполагаю, поэтому мы ничего не деплоим в продакшин»). Но третий человек должен быть для принятия бизнесс решений (хотя-бы сделать выборку тех багов которые должны быть пофикшены перед релизом), и желательно образование\опыт этого человека должно быть хоть немного лежать в плоскости ИТ или разрабатываемого продукта. Меня сейчас кинули на проект, который уже давно жёстко отстаёт от сроков. Девелоперы просто игнорят все имейлы и тикеты от QA. А ПМ на проекте только для навешивания лапши кастомеру и проведения Daily stand up. Смотреть список открытых багов это из разряда космических технологий, да и если продемонстрировать как это сделать — пользы никакой.
Вы лучше расскажите как избавиться от кучи багов в интерфейсе?
1) Missed Conversations могут всплывать через 2 недели. При чём 90% случаев это чаты в которых есть мои активные ответы, но «непрочитанными» являются все сообщения собеседника.
2) Непонятное автопереключение активного чата, когда пол сообщения пишешь одному человеку, а вторая половина уже набирается в другом чате.
3) Баг интерфейса, когда активным отображается чат с «Васей Пупкиным», а сообщение уходит «Джону Смиту».
4) Супер юзер кейс, когда «Continue Conversation» вставляет историю переписки в КОНЕЦ текущего чата, а не сортирует по дате.
5) Из недавнего — «Join Skype Meeting» создал для каждого из 7 участников 7 отдельных чатов к которым больше никто другой не мог присоединиться.
6) Зависающая «демонстрация экрана» без какого-либо уведомления хотя-бы о «качестве соединения», при том что все участники митинга могут сидеть в одной комнате. И это при том что для наших «эффективных менеджеров» это является «киллер фичей».
7) Ещё один гениальный ход UI — запретить докать окно чата и окно контактов.
8) Прозрачная рамка вместо интерфейса после ухода в сон (читай «закрытия крышки ноутбука»).

Я могу так долго продолжать. И это только за 2 месяца пользования S4B ака Lync. Более отвратительного продукта для бизнесса я ещё не видел.

P.S. Это не критика статьи или автора. За «хинты» спасибо, но этим «продуктом» пользоваться без нервов невозможно.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность