Канал IBS Training Center - это возможность увидеть записи выступлений наших экспертов, практиков с уникальным опытом работы в реальных проектах по разработке ПО.
В нашем плейлисте вы найдете полезный контент по важнейшим дисциплинам Software Engineering: разработка ПО (Java, Web, C, C++, .NET), системный и бизнес-анализ, архитектура и проектирование ПО, Big Data, тестирование ПО, администрирование ПО, управление проектами по разработке ПО и др.
Записи семинаров, тренингов, докладов с профильных конференций - все это доступно для наших подписчиков. Присоединяйтесь!
Отличный материал. Но ролик, который должен объяснить почему стоит выбрать Java сводится к тезису - java лучше python. Что само по себе намекает, что есть с этим серьезные проблемы.
Все попытки заменить sql через linq и expression trees так и не достигли успеха, т.к. как ни крути, но описать сложный запрос понятнее и короче, чем в sql c# не может, но эти попытки говорят о том, что новые поколения программистов не сильны в языках запросов и предпочитают все кодить в языке высокого уровня, упуская из виду, что sql разрабатывался именно для работы с множествами и, хотя он очень стар и местами неуклюж, с множествами в нем до сих пор работать гораздо удобнее.
Почему то не обсуждается сравнение с тем же Go, адепты которого постоянно указывают на то, что сервисы написанные на Java в 12-14 раз прожорливее по ресурсам, нежели тоже самое реализованное на Go, С учетом тотальной популярности микросервисов, этот вопрос как никогда актуален. Да, я сам в спорах часто оперировал аргументами: "Можно использовать GraalVM", "Можно использовать не дефолтные ГК", "Зачем использовать для примером тяжеловесный Spring?", "Можно использовать не дефольный TomCat, а другой сервер"... но на все, постоянно отвечают "А зачем, если в другом ЯП, это все меньше, быстрей и сразу из коробки?". Как быть в этом случае?
О чём вы? О каких реальных сравнениях идёт речь? Почему учёные сравнивая 27 языков по энергоэффективности и времени поставили Java выше Go и только по использованию памяти она сильно от него отстала? Но там по памяти даже и C оказался не на 1 месте, а лишь на третьем после Pascal и Go. Т.е. единственная категория по которой Go вышел почти в лидеры и выделялся на общем фоне и то им была проиграна Pascal. С ваших слов теперь Pascal ещё более лучший язык получается или как это понимать?
Да, с записью и демонстрацией явно какая-то проблема. Скорее всего у слушателей было куда чётче на экране (в 1080p, в отличие от записи на 720p). Но в конце записи вэбинара есть ссылка на исходный код в Gitlab внутри QR-кода
на 14 -м слайде термин "спонсор проекта" употреблен некорректно с точки зрения стандартов проектного менеджмента. В частности - стандарта PMBoK. Там же имеется немного другое описание заинтересованной стороны проекта. Автор по ходу доклада не понимает различий между бизнесом как операционной деятельностью, проектом создания системы как способом развития этого бизнеса (переходом бизнеса из точки А в точку Б), и продуктом (результатом) такого проекта - ИС. Поэтому немного смешались в кучу кони люди - стейкхолдеры проекта, стейкхолдеры бизнеса и пользователи системы. И поэтому для него стейкхолдеры "сложно определимое понятие". А для зрителя не совсем понятно почему одних заинтересованных сторон берем в расчет, а других откидываем. А так вполне на уровне. Спасибо!
"Частично запросы генерируются JavaScript`ом." Звучит опасно. Как бы нельзя было туда чет заинжектить с запросом на стороне клиента(браузера) и на бд какойнить делит загнать)
вы писали в телеграм-канале, что это новость дня. я не очень понял, а в чём именно новость? "директор учебного центра рассказал об актуальности ЯП Java" - т.е. директор учебного центра способен рассуждать об актуальности ЯП, в этом новость?
Слайд с резюме/вакансии не очень информативный, а так всё толково. С сертификациями непонятно куда всё приведёт. Это наверное больше важно для гос заказчиков и для сертификационных центров.
Забавно.... Мы хотим сделать всероссийскую сертификацию но курсы проходите у нас.. ну продажа удалась, на правильном английском .. Пардон, какая то дикая самодеятельность, давайте будем опираться на материалы общепризнанные.... а не то что контора на придумывала, ибо кушать хочется и надо докрутить чтобы продать.
Здравствуйте! Мы действительно стремимся разработать всероссийскую сертификацию, привлекая для партнерства отечественные компании ("Сколково", "БеллСофт"). Прохождение подготовительных курсов не обязательно. Они были разработаны для тех, кто хочет подготовиться к сертификации и "подтянуть" свои знания Java. Однако, сделать это можно самостоятельно, просто запросите у нас список экзаменационных тем.
Лучшее объяснение асинхронности, спасибо! Если это видео посмотреть в самом начале, то можно сразу вникнуть в смысл асинхронности и не плавать с фьючерами.
41.35 (time code) - на текущий момент Visual VM 2.1.2. При работе Sampler, видно четко время выполнения smallMethod(), не смотря на то, что он быстрее всех выполняется. ThreadDump также показывает вызов этого метода. В stackTrace это видно.
В видео говорится, что время, затрачиваемое на bigMethod в профайлинге, учитывается отдельно от времени, затрачиваемого на вызов smalMethod из bigMethod. Не уловил мысль: в режиме сэмплирования такое же правило ?
@@user-dt2me5sy9s думаю не так. Здесь делался акцент на то, что когда происходит сэмплирование, то оно не детализирует вызов методов, которые занимают очень малое количество времени. А когда запускается профилирование, то оно оборачивает сквозной логикой каждый профилируемый метод: то есть каждый метод, который профилируется в начале своей работы и в конце, с него снимаются временные метки, на основе которых и вычисляется время работы метода. Сэмплер, "снимает" данные с потока(он как бы "цепляется на поток, а для этого он его ищет через ThreadGroup"), в котором выполняются методы и от JVM, получает информацию об используемых ресурсах и вычисляет время работы.
