Да, экран в 10-11 дюймов удобней, чтобы читать литературы в электронном виде, серфить в интернете, сделать какую-то несложную работу. У меня был iPad - был довольно хорош, кроме того, что в него нельзя просто так взять и воткнуть флешку USB с компа с данными. Я купил ноутбук трансформер 13.3 и оказалось что он может все, что и iPad, только я на нем могу запустить и глянуть по быстрому программный код и что-то подсказать коллегам или по-быстрому поправить, с ним удобней переносить данные, да и в целом винда оказалась привычнее. Но минус в том, что он весит 1,5 кг и громоздкий, когда его надо превратить в планшет.
Я бы пощупал в руках OneMix 4S. Возможно он будет сочетать в себе удобство планшета и ноутбука на винде. При этом нужен довольно мощный, чтобы переварил Visual Studio с открытым проектом.
Планшетов на винде крайне мало. Либо китайское говно, либо говно-леново. У меня был ноут hp 360 13 дюймов. Кроме веса и размера - оказался удобен тем, что он превращался в планшет на винде, где все привычно.
На любой машине можно боятся ездить больше 40. Зависит от условий. Накатанному льду под горку все равно насколько там премиальная резина. Физику не обманешь.
Да и полушары обычно ставят там где нельзя ездить (тротуары, газон). Зачем в таких местах сдавать назад - в голове не укладывается.
Мне кажется ACID - это более фундаментальные вещи. В статье описана логическая блокировка записей. Например порция данных, которую мы взяли в обработку.
Но даже если продолжать в том же духе - как всегда "все зависит от".
В Oracle и MS SQL я мог, используя Serializable или Repeatable read, сделать обновление логического флага/статуса. А вот в MySQL такой финт не прошел, база начинала выдавать разные записи, и вроде даже дубли. Я дальше не стал раскапывать, так как в том проекте уже была еще одна внешняя блокировка, кстати в виде таблицы в том же MySQL. А вот когда я эту таблицу заменил на RedLock на основе Redis - проекту в целом похорошело.
В модуль банке все проще. Валютный контроль бесплатный. Мобильное приложение удобное. В июне комиссия на входящий SWIFT перевод была 20 баксов. Платеж шел 3-4 дня. Банк корреспондент австрийский райффайзен. Обмен валюты на бирже по курсу биржи + 0,5% что ли. Бесплатный вывод на физ лицо - 300 тр /мес на среднем тарифе.
Надоела одна и та же теория. А когда доходит до практики - там столько проблем всплывает. Лучше бы рассказали в деталях как было, как стали переводить, с какими проблемами столкнулись и как решали.
Что вы делали когда обработка бизнес запроса стала запаздывать из-за кучи обращений по сети и вышли за пределы требований в 1-3 секунды на один запрос?
Что вы реально делали с распределенными транзакциями? А не абстрактные рассуждения про саги и двухфазные комиты
Какое средство вы применили, когда потребовалось трейсить время прохождения запроса по всем микросервисам, чтобы знать какой именно микросервис тормозит или какая именно БД?
Что там насчет version hell? Вот серьезно - одному клиенту надо часть бизнес процесса обрабатывать по версии 1, для другого клиента по версии 2. Про слабую связанность - это все сказки. Красиво только на учебном примере. В реальности в одном месте поднял версию апи, в других местах понавешал костыли.
Кафку использовали для взаимодействия микросервисов? Что там насчет авто масштабирования?
Забавные эксперименты. Помнится было что-то про время распада протона, вроде 10^32 степени лет (википедия говорит минимальный порог 2,9*10^29). Даже эксперимент начали. Только пока результаты отрицательные. Так и ежику понятно. Ведь вселенная существует только 1,5*10^10 лет. Надо еще чуть-чуть подождать.
В одном из проектов есть учет по SKU (уникальный ид номенклатуры). Необходимо сделать поддержку партийного (номер партии/лота, например для товаров со сроком годности) и серийного (например серийный номер ноутбука) учета.
Или например продумать обработку бэк-ордеров (это когда заказ исполнен не полностью, и на остаток надо оформить отдельный заказ).
Тут надо знать предметную область, ее особенности. Плюс знать текущий проект и его функции, чтобы расписать на концептуальном и функциональном уровне что и где поправить и доработать. В дебри технической реализации лезть не нужно. Но нужно понимать, что есть сущности и связи между ними (что по факту уже близко к структуре БД).
Описание должно быть довольно компактным, а не на десятки страниц, как было с тем системным аналитиком. Человек должен понимать, сколько примерно делать то, что он там придумал (можно и у программистов спросить в сложных случаях). Потому что аджаил, и пользователь не будет ждать полгода. Т.е. еще нужно и уметь приоритезировать, облегчать, выделять главное.
Да, программисты сейчас этим и занимаются, в целом ок. Просто работы много. Хотелось бы разгрузить.
Так а БА же не сможет в технику. Не его задача. Будет каждый раз ходить к программистам с вопросом "А можно ли так сделать?". Ну или я не доконца понимаю роль БА.
Актуальная для меня тема. Работаю в компании, где есть продажники, менеджеры проектов (на них лежит коммуникация и координирование, организационные моменты) и программисты. Необходимо закрыть этап выслушивания, анализа и перевода хотелок клиентов в таски для программистов.
Компания продуктовая, несколько проектов (SaaS). Продукты взаимосвязаны между собой и покрывают различные этапы бизнес процессов в предметной области (логистика). И по этой причине одна хотелка клиента может преобразоваться в таски для 1..n продуктов.
Пробовали системного аналитика - не взлетело. Концентрировался на одном проекте, проблемы из-за не знания предметной области. И человек до этого работал в системных интеграторах, а у нас тут аджаил. В общем сначала уходила неделя на тонну текста, потом это откладывалось, потому что кодить это полгода. И так по каждой хотелке пользователей.
Хорошо что я отказался от столь щедрого предложения в свое время. Таких подробностей мне не рассказывали.
Гениально
Да, экран в 10-11 дюймов удобней, чтобы читать литературы в электронном виде, серфить в интернете, сделать какую-то несложную работу. У меня был iPad - был довольно хорош, кроме того, что в него нельзя просто так взять и воткнуть флешку USB с компа с данными. Я купил ноутбук трансформер 13.3 и оказалось что он может все, что и iPad, только я на нем могу запустить и глянуть по быстрому программный код и что-то подсказать коллегам или по-быстрому поправить, с ним удобней переносить данные, да и в целом винда оказалась привычнее. Но минус в том, что он весит 1,5 кг и громоздкий, когда его надо превратить в планшет.
Я бы пощупал в руках OneMix 4S. Возможно он будет сочетать в себе удобство планшета и ноутбука на винде. При этом нужен довольно мощный, чтобы переварил Visual Studio с открытым проектом.
Планшетов на винде крайне мало. Либо китайское говно, либо говно-леново. У меня был ноут hp 360 13 дюймов. Кроме веса и размера - оказался удобен тем, что он превращался в планшет на винде, где все привычно.
Жесть, вот это истории…
На любой машине можно боятся ездить больше 40. Зависит от условий. Накатанному льду под горку все равно насколько там премиальная резина. Физику не обманешь.
Да и полушары обычно ставят там где нельзя ездить (тротуары, газон). Зачем в таких местах сдавать назад - в голове не укладывается.
Мне кажется ACID - это более фундаментальные вещи. В статье описана логическая блокировка записей. Например порция данных, которую мы взяли в обработку.
Но даже если продолжать в том же духе - как всегда "все зависит от".
В Oracle и MS SQL я мог, используя Serializable или Repeatable read, сделать обновление логического флага/статуса. А вот в MySQL такой финт не прошел, база начинала выдавать разные записи, и вроде даже дубли. Я дальше не стал раскапывать, так как в том проекте уже была еще одна внешняя блокировка, кстати в виде таблицы в том же MySQL. А вот когда я эту таблицу заменил на RedLock на основе Redis - проекту в целом похорошело.
В модуль банке все проще. Валютный контроль бесплатный. Мобильное приложение удобное. В июне комиссия на входящий SWIFT перевод была 20 баксов. Платеж шел 3-4 дня. Банк корреспондент австрийский райффайзен. Обмен валюты на бирже по курсу биржи + 0,5% что ли. Бесплатный вывод на физ лицо - 300 тр /мес на среднем тарифе.
ООП в SQL, абалдеть…
Надоела одна и та же теория. А когда доходит до практики - там столько проблем всплывает. Лучше бы рассказали в деталях как было, как стали переводить, с какими проблемами столкнулись и как решали.
Что вы делали когда обработка бизнес запроса стала запаздывать из-за кучи обращений по сети и вышли за пределы требований в 1-3 секунды на один запрос?
Что вы реально делали с распределенными транзакциями? А не абстрактные рассуждения про саги и двухфазные комиты
Какое средство вы применили, когда потребовалось трейсить время прохождения запроса по всем микросервисам, чтобы знать какой именно микросервис тормозит или какая именно БД?
Что там насчет version hell? Вот серьезно - одному клиенту надо часть бизнес процесса обрабатывать по версии 1, для другого клиента по версии 2. Про слабую связанность - это все сказки. Красиво только на учебном примере. В реальности в одном месте поднял версию апи, в других местах понавешал костыли.
Кафку использовали для взаимодействия микросервисов? Что там насчет авто масштабирования?
Забавные эксперименты. Помнится было что-то про время распада протона, вроде 10^32 степени лет (википедия говорит минимальный порог 2,9*10^29). Даже эксперимент начали. Только пока результаты отрицательные. Так и ежику понятно. Ведь вселенная существует только 1,5*10^10 лет. Надо еще чуть-чуть подождать.
Задротство и интерес в компьютерной сфере
Любознательность и желание докопаться
Технический вуз, есть специальности вроде "прикладная информатика в ...", там меньше математики и алгоритмов и больше фокуса на предметной области
Самообучение по толстым книги по языкам, фреймворкам, проектированию
Самообучение по решениям других программистов
Ну наконец-то, (мечтательно) тачки подешевеют
Книга - это не практика и не реальный опыт. Я на собесах тоже даю задачу на системный дизайн, осознанные ответы у людей с 10+ опыта.
Интересно как прошло собеседование по системному дизайну, с учетом 4 лет опыта.
Есть такое, ездил на окраину - разумеется в центре лучше. Чище, ухоженней, больше зелени, красивые здания.
Ничосе, в мае был в Ташкенте - показался очень зеленым городом с кучей тени. Не то что в России.
Пример задачи.
В одном из проектов есть учет по SKU (уникальный ид номенклатуры). Необходимо сделать поддержку партийного (номер партии/лота, например для товаров со сроком годности) и серийного (например серийный номер ноутбука) учета.
Или например продумать обработку бэк-ордеров (это когда заказ исполнен не полностью, и на остаток надо оформить отдельный заказ).
Тут надо знать предметную область, ее особенности. Плюс знать текущий проект и его функции, чтобы расписать на концептуальном и функциональном уровне что и где поправить и доработать. В дебри технической реализации лезть не нужно. Но нужно понимать, что есть сущности и связи между ними (что по факту уже близко к структуре БД).
Описание должно быть довольно компактным, а не на десятки страниц, как было с тем системным аналитиком. Человек должен понимать, сколько примерно делать то, что он там придумал (можно и у программистов спросить в сложных случаях). Потому что аджаил, и пользователь не будет ждать полгода. Т.е. еще нужно и уметь приоритезировать, облегчать, выделять главное.
Да, программисты сейчас этим и занимаются, в целом ок. Просто работы много. Хотелось бы разгрузить.
Так а БА же не сможет в технику. Не его задача. Будет каждый раз ходить к программистам с вопросом "А можно ли так сделать?". Ну или я не доконца понимаю роль БА.
Я встречал
Актуальная для меня тема. Работаю в компании, где есть продажники, менеджеры проектов (на них лежит коммуникация и координирование, организационные моменты) и программисты. Необходимо закрыть этап выслушивания, анализа и перевода хотелок клиентов в таски для программистов.
Компания продуктовая, несколько проектов (SaaS). Продукты взаимосвязаны между собой и покрывают различные этапы бизнес процессов в предметной области (логистика). И по этой причине одна хотелка клиента может преобразоваться в таски для 1..n продуктов.
Пробовали системного аналитика - не взлетело. Концентрировался на одном проекте, проблемы из-за не знания предметной области. И человек до этого работал в системных интеграторах, а у нас тут аджаил. В общем сначала уходила неделя на тонну текста, потом это откладывалось, потому что кодить это полгода. И так по каждой хотелке пользователей.
Какие варианты вообще есть?
Сами думаем над следующими:
Обучение программистов предметной области
Выделенный эксперт по предметной области
Продукт овнер