• Как я ушел из IT в психологию
    0

    Сначала троих детей воспитайте… Потренируйтесь на кошечках )))
    [кадр из к/ф Операция Ы]

  • Как я ушел из IT в психологию
    +1

    Да… вы еще точнее сформулировали мою идею. Сколько людей, столько и теорий.

  • Team Lead на удаленке: как я путешествовал с семьей и работал из Греции и Вьетнама
    0

    В Бангкоке (кажется недалеко от Nana Station) есть арабско-кавказский квартал, в кафешках которого в меню надписи на Тайском и Русском. Есть "Окрошка", но нет "Okroshka" ;)

  • Team Lead на удаленке: как я путешествовал с семьей и работал из Греции и Вьетнама
    0

    Соррян… у меня с географией туго… Я думал это выдуманый город. Хотел написать "из русской глубинки". В этом смысле Саратов === Урбпинск

  • Как я ушел из IT в психологию
    0

    Ну так-то да… Меня следует читать так:
    "Может для утоления жажды психологии было бы достаточно базового левела менеджмента индивидуальностей? Может полноценная психология — это уж черезчур?"


    Меня вот в школе учительница по французскому тащила в переводчики, но мне инженерия более интересна была. Я от нее взял базовый уровень (задел) и дальше не стал углубляться. Так и тут.


    Автор решил переквалифицироваться (или даже "переродиться") в Клинического Психолога, что довольно радикальное перепрофилирование. Как если б "водитель трамвая" в "погромисты" подался.

  • Как я ушел из IT в психологию
    +3

    Когда в IT дорастаешь до Team Lead, то психологии становится хоть отбавляй. Начинаешь озабочиваться психологической совместимостью членов команды, эмоциональным интеллектом, конфликтологией и прочими прелестями тонкой псих. организацией индивидуумов.


    Может и нет смысла уходить в психологию на фулл-тайм?

  • Как я ушел из IT в психологию
    0

    На КДПВ в последнем пункте (как видит психолог) загогулин должно быть значительно больше (мнение близко знакомого педагога-психолога: ).

  • Team Lead на удаленке: как я путешествовал с семьей и работал из Греции и Вьетнама
    +2

    Идешь с друзьями по Паттайе на расслабоне… наслаждаешься экзотическим видом азии.
    И тут бац! Две бабы с Урюпинска с огромными сумками и выпученными глазищами налетают и орут сквозь дыхание загнанной лошади:
    "Где здесь ярмарка шуб и дубленок из Греции?"

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    Да вы правы. Я смешал две техники. И происходит это потому что у них есть общее. Смешивание декларативки с кодом c#. А разница между <% и @ уже несущественна. Смешивание разных парадигм в одном файле — гадство.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0
    На тему статической типизации во фронте… Я сам и WebForms писал в своё время и Wpf сейчас пишу и честно говоря вообще никакой проблемы в статической типизации во фронте не вижу. Я ей даже рад, поскольку с ней всeвозможные предшественники, коллеги, подчинённые и авторы сторонних библиотек могут мне нагадить гораздо меньше чем без неё.

    Рукожопы (профессиональные) могут нагадить изрядно и с тем и с другим. Это вопрос культуры проганья, тимлидинга и ревью.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    –1
    Дальше перейдём к Razor. Проблема Razor не в том, что он использует C#, а в том что запилен исключительно под MVC паттерн. И C# код там выполняется исключительно в момент генерации вьюшки. Замените в Razor C# на JS или любой другой язык программирования и ничего не изменится.

    С разором проблема главная в НЕудобстве использования. Смешение парадигм и языков. С ним в презентационном слое получается месиво из 4х языков: c#, js, css, html.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    –1

    Наверняка через матёрый прослой и бубнотанцы как было в сервелате.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    А потом вслед за рантаймом ещё летят сборки второстепенные. Я тоже видел видео с вкладкой Network в хроме.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    Даже в .net core ещё вроде не научились стрипать сборки, чтоб облегчить дистриб и потребление памяти (все сборки грузятся целиком). Поправьте меня если неправ.
    Если научат CLR стрипать сборки, тогда может и облегчится. А пока они идут по пути сервелата. Пытаются оптимизировать код в сборках, чтоб они были меньше. Сбрасывают жир в ущерб функциональности.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    Пример:
    Visual Studio против VS Code.
    Функционал для рядового девелопмента у Code не намного скуднее. Даже иногда наоборот.В Code можно отлаживать Xamarin Android на реальном телефоне, а с VS хз как… Я не нашел способа подрубить дебаггер.


    Code написана на js и летает
    VS написана на убогом старом VS Shell (c++) а поверх натянут WPF. Топмозит, жрет памяти вагон, и размер установки с нужными тулзами под 30ГБ на системном диске.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    Я знаю и то и другое на высоком уровне. Ни в жисть не буду с js слазить. Хватило мне с головой winforms и webforms. Если на шарпе, только wpf с XAML.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    Нормальный инж должен под конкретную задачу осваивать подходящие инструменты. Мы ж не Кижи строим, чтоб все без гвоздей и только топором. Иначе получается карго-культ типа: "я только в сишарп" Как в раге: "кто запоёт, тот лох"

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    В ui динамический язык, duck typing в сочетании сдеклараьивным подходом дают больше профита чем статическая типизация.
    Как ui разраб на WPF с 2007 года я вас уверяю, что со статической типизацией во фронте под десктоп тоже не сладко. Довольно много сил отнимают церемонии с полиморфизмом, интерфейсами и согласованиями зависимостей. А уж как вы будете писать на шарпе ui я даже представить боюсь.


    Было у меня щастье от индусов разных национальностей в поддержку получать WinForms файл главного окна на 25 килострок. Ужосна хххх. Дай то б-г чтоб вам такое не довелось попробовать.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    В вебфреймворках размер бандла распухает подключением Materials Design и прочих нахлобучек, которых блазоре нет также. Тут ничья. А вот .net runtime не стрипается вообще. Это фундаментальный косяк, что с приложением в память грузятся целиком сборки. Так же и в блазоре щас. Через сеть тянется весь рантайм. Изменится сишарп твоей логики и рантайм заново будет сосаться или браузер сможет в глобальный кэш положить рантайм (GAC в браузере)?

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    –1

    Язык будет один, но подходы все равно в корне отличаются. С блазором бэкендеры будут шурупы забивать молотком и наждачной бумагой полировать поверхность воды.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    –1

    Один язык — это все фигня. Меня ни в жисть не заставишь на шарпе писать вебовский фронт. Хватит… Надрался я этого долбаного Razor в WebForms с треклятыми постбэками.
    Для меня разор… Тьфу… Блазор суть удачное сочетание недостатков WebForms и Silverlight. И предательство M$ с SL/WPF я не забуду. Вместо исправления графического стэка для подъёма производительности они пилят новый сервелатФормз.


    ПыСы: я на WPF с 2007 года (а может даже чуть раньше, не помню уж) и для меня VueJS значительно соблазнительные.

  • Blazor + MVVM = Silverlight наносит ответный удар, потому что древнее зло непобедимо
    0

    А по моим наблюдениям сервелат начали прибивать по политическим соображениям, когда никаких технических препятствий не было. Он мне как технология напомнил песню Бритни: I'm not a girl. Not yet a woman.


    В сравнении с WPF он был неудобен и менее функционален. Плюс неудобная модель дистрибьюции и ещё больше проблем сперфомансом, чем у WPF.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0

    "Критикуешь — предлагай альтернативу"

  • Сначала фронт, а потом бэк (когда-нибудь)
    0

    Конечно, имел опыт.
    К пейджеру обязательно поисковик и фильтр по некоторым полям. Это стандартные вещи UX.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0

    Спасибо! Надо будет поизучать на досуге.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0

    я про то, что частями слать не получится… или есть либа для парсинга XLSX в JS?

  • Сначала фронт, а потом бэк (когда-нибудь)
    +1

    я вас понимаю… главная цель в контексте статьи — при фиксированном составе команды максимально ускорить разработку конкретной фичи при минимизации рисков больших переделок.


    ваше предложение в иной ситуации также уместно. Если, напр., в дополнение к основной фиче взять тех долг или обращения в ТП, то именно ваш вариант и выйдет.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0

    Про csv это к примеру было. Для простоты. Может быть и другой формат (xlsx напр.)

  • Сначала фронт, а потом бэк (когда-нибудь)
    +1
    я вижу разбиение задач и их планирование у вас как в waterfall, но при этом аргументируете это гибкой разработкой и скоростью

    Гибкие методологии разве требуют избавиться от планирования?
    Спринт планируется. Базовая спека от PO насыщается деталями аналитика в команде или самими разработчиками. В пределах спринта (по скраму если) всеми силами нужно придерживаться плана на спринт. Без планирования в аджайл получаем канбан, в котором команда просто отрабатывает прилетающие в реалтайме карточки на доске (конвейер).

  • Сначала фронт, а потом бэк (когда-нибудь)
    +2
    так вы пытаетесь выдавить скорость из разработки, паралеля все что можно, но при этом все равно привязаны к сроку спринта в 7 или 14 или сколько там у вас он идет и фидбэк будет собран не раньше его окончания, а если фидбэк будет собран раньше то зачем спринты? и релизы вне спринта.

    На тестовую среду можно доставлять из ветки dev. Показать прототип PO или ещё какому-нибудь внутреннему пользователю можно значительно раньше, не синхронизируясь с циклами разработки других команд.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0

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

  • Сначала фронт, а потом бэк (когда-нибудь)
    0

    С комнатой — это годный вариант. Учту на будущее.


    Так-то я согласен что long polling не лучшее решение.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0
    Стопиццот дофигаллиардов позиций, ага))

    Пейджер естественно.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0
    точно также и про процесс разработки, чем он проще и легче, тем больше времени на разработку, это лишь мое имхо возможно я ошибаюсь.

    Тут вы правы. Я сам за максимально простую реализацию. В заключении как раз и написал про это. Возможно, церемонии с бранчами и не нужны вовсе, если девелоперов договорились о работе в отдельных папках или файлах.

  • Сначала фронт, а потом бэк (когда-нибудь)
    +1
    Так у вас же спринты, вы в начале спринта делаете ветку спринт№123 и она становится dev веткой, а когда спринт заканчивается вся ветка вливается в мастер и релиз (ну так по обычному git flow).

    Гит флоу и расписание спринта разных команд — это совсем разные темы. Кроме того гит флоу — это рекомендация и всегда подлежит адаптации под конкретную команду. Не всем заходит гит флоу в полной реализации.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0
    разработчикам работающим над импортом придется учитывать и влитые эти задачи и при merge или rebase могут возникнуть конфликты, далее разработчики что не влили в ветку импорта, придется делать тоже самое (мержить или ребейзить свои правки) на актуальные данные.

    Ветка import-dev в мастер будет сердиться только когда есть уверенность в ее стабильности (проверена qa и дана резолюция, что критических багов нет). К этому моменту все атомарные ветки девелоперов уже должны быть влиты в dev. Как я писал ранее. Дальше будет ребейз или мерж двойной. Почти наверняка будет конфликт в yarn.lock + быть может в package.json. других конфликтов с чужими мержами в мастер не должно возникнуть, если не правили общие компоненты.

  • Сначала фронт, а потом бэк (когда-нибудь)
    –1
    В том-то и дело, что в случае использования WS оба уверены. На обеих сторонах есть события on[connect,disconnect] и т.п

    Вы меня недопонял, кмк. На низком уровне как реализован Persistent Connection? Как две программы на двух разных компьютерах определяют, что коннекшен ещё жив?
    Все мои комментарии были о том, как технически это может быть реализовано.
    WS — это же не UDP.
    Мне кажется интересным разобраться в тех. деталях коннекшена через WS и конкретно SignalR.


    И кстати вам должно быть известно, что SignalR перед установкой коннекта пробует несколько протоколов (в зависимости от поддержки на стороне сервера). Оттого может зависеть, какой подход выгоднее.

  • Сначала фронт, а потом бэк (когда-нибудь)
    +1

    Ну можно было подобрать пример и посолиднее. Просто увеличилось бы количество воды.

  • Сначала фронт, а потом бэк (когда-нибудь)
    0
  • Сначала фронт, а потом бэк (когда-нибудь)
    –5
    1. Статья не про SignalR. Детали реализации общения через WebSocket для целей статьи несущественны.
    2. Подробно в подкапотных деталях работы SignalR и Websocket в целом копатья не доводилось. Согласно диаграммам в этом пособии и представлениям о сетях коммуникаций видится следующее:
      а) Клиентская либа (SignalR напр.) инициирует Persistent Connection. Как это работает? Оба конца должны быть уверены, что коннекшен еще жив. Проверить это можно отправкой короткой датаграммы с неким периодом. Об этом я и писал.
      б) Пока коннекшен жив мы можем слать данные туда-сюда и уже не важно чья инициатива начать отправку (событие в сервере или браузер клиента).

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


    Тут еще играет роль то, что мы имеем ферму инстансов серверов с балансировкой. В результате техническая сложность реализации подхода с пушем события растет сильно.


    Для MVP было решено не переусложнять решение (для первого опыта с SignalR лучше попроще было сделать). SignalR Hub в итоге работает подобно WebAPI Controller, но транзакции значительно эффективнее. Переделать такое решение на нормальную событийную коммуникацию не очень сложно.