PUSSY (Python Utilitarian Script System for You) - это кроссплатформенный программный комплекс, который позволяет ускорить разработку приложений с графическим интерфейсом на языке Python и PySide6. Его ключевой фичей является быстрое создание раздела с пользовательскими настройками, достаточно просто объявить перечень Свойств в Специальном контейнера, а система сама позаботится обо всем остальном. Нажимайте на "Читать далее" чтобы узнать как с этим работать и как можно самостоятельно расширить его возможности под собственные потребности...
В этом релизе мы рады представить специальный редактор конвейеров (в русской локализации GitLab «сборочные линии»), панель управления частотой развёртываний и несколько улучшений качества работы, которые сделают повседневное использование GitLab ещё более комфортным. И это — всего лишь несколько основных моментов из более чем 50 улучшений этого релиза!
Вышел релиз GitLab 13.5 со сканированием безопасности мобильных приложений, вики-страницами групп, общим реестром пакетов и многими другими классными фичами!
Команда GitLab стремится к повышению производительности и степени удовлетворённости разработчиков. Релиз 13.6 содержит все необходимые ингредиенты, которые помогут вам достичь этого и, возможно, чего-то ещё! Мы надеемся, что вам пригодятся основные фичи релиза, а также ещё более 60 новых фич и улучшений, добавленных в этом релизе.
Ну и год же был 2020! Мы счастливы представить релиз 13.7 с более чем 45 фичами и улучшениями поставки ПО, вышедший как раз к праздникам.
От имени всех сотрудников GitLab мы хотим поблагодарить участников нашего сообщества за ваш вклад и за то положительное влияние, которое вы оказываете на нашу работу. Без вас GitLab не был бы таким, как сейчас.
Благодарим вас и всех членов команды GitLab, которые помогли сделать 2020 год невероятным, несмотря на невзгоды и непредсказуемые обстоятельства. Пожалуйста, оставайтесь в безопасности, будьте счастливы и здоровы в этот праздничный период.
В прошлом году впервые в России прошёл конкурс Imagine Cup: встраиваемые системы — и результат превзошел все наши ожидания, российская команда заняла 2 место в мире в этом конкурсе. В этом году конкурс встраиваемых систем снова проводится в России — для участия необходимо подать заявку на участие в конкурсе до 20 декабря 2010 г. 6 команд-финалистов получат устройства eBox для реализации своих идей на практике, а команда-победитель будет представлять Россию на международном финале летом 2011 г. в Нью-Йорке. Все, кто умеет/любит держать в руках паяльник и может программировать — участвуйте в конкурсе встраиваемых систем и приносите России очередную победу!
13 декабря 2013 г. в Минске пройдет четвёртая международная конференция Application Developer Days.
Application Developer Days — это конференция, сделанная программистами для программистов. Для тех, кто непосредственно пишет код, продумывает архитектуру приложения и старается повысить свою продуктивность, используя новые языки и библиотеки. Кроме непосредственно программистов, конференция будет интересна всем тем, кто вовлечен в процесс создания программных продуктов, кто хочет понять, чем живут разработчики, посмотреть на всё с точки зрения программиста.
Пост о том, почему наши программисты теперь заполняют таймшит не 32, а только 2 минуты и о том, как можно наладить автоматический учет рабочего времени за счет импорта данных из трекинговых систем TFS, Redmine и Jira на Microsoft Project Server.
Статья будет интересна менеджерам проектов, руководителям компаний-разработчиков, а также программистам, интересующимся интеграцией различных систем управления проектами.
Проблема — бардак в заполнении таймшитов
Для 99% компаний-разработчиков учет рабочего времени программистов нужен как воздух, чтобы считать затраты.
PVS-Studio выполняет анализ C/C++ кода и подсказывает программисту, где скрываются ошибки, или указывает на участки кода, которые могут стать проблемными в будущем. Если разрабатываемый проект достаточно большой, то анализ может занимать весьма много времени. Для ускорения анализа большого проекта можно воспользоваться инструментом IncrediBuild. Если у вас уже установлен анализатор PVS-Studio и инструмент IncrediBuild, то из статьи вы узнаете, как их можно подружить и добиться ускорения анализа. В дальнейшем анализатор PVS-Studio будет еще плотней интегрироваться с IncrediBuild. Но ещё раз повторим, что распараллелить запуск PVS-Studio на нескольких машинах можно уже сейчас. Это просто. И в статье мы расскажем, как это сделать.
PVS-Studio — статический анализатор, выявляющий ошибки в исходном коде приложений на языке C/C++. Подобно компилятору, анализатор обходит файл за файлом в каталоге с исходниками проекта, выполняя свою задачу. Но и без использования внешних инструментов, сборка некоторых проектов может длиться несколько часов. Статический анализ такого проекта будет занимать ещё больше времени. Для сборки крупных проектов, некоторые разработчики прибегают к использованию распределённой сборки с помощью инструмента IncrediBuild. В данной статье не будут рассмотрены детали интеграции PVS-Studio в IncrediBuild, а будет рассказано о проверке большого проекта, замерах времени и других интересных фактах.
Исключая тех, кому повезло быть богатыми, большинство людей занимают деньги, когда начинают свой первый бизнес. И они надеются, что эти инвестиции себя оправдают. Это пример того, как долг может быть хорошей штукой.
То же самое относится к техническому долгу. Бесчисленное множество статей в интернете рассказывают, как от него избавиться или хотя бы уменьшить. Все эти статьи показывают технический долг каким-то монстром, которого надо избегать. А если не получилось – то бороться изо всех сил.
В программировании и в TDD, в частности, есть хорошие принципы, которых полезно придерживаться: DRY и тестирование через public-методы. Они неоднократно оправдали себя на практике, но в проектах с большим legacy-кодом могут иметь «тёмную сторону». Например, ты можешь писать код, руководствуясь этими принципами, а потом обнаружить себя разбирающим тесты, охватывающие связку из 20+ абстракций с конфигурацией, несоизмеримо превосходящей по объему тестируемую логику. Эта «тёмная сторона» пугает людей и тормозит использование TDD в проектах. Под катом я рассуждаю, почему тестировать через public-методы плохо и как можно уменьшить проблемы, возникающие из-за этого принципа.
В статье про тестирование public-методов коснулся юнит-тестирования приватной логики классов. Думаю, мне стоило бы переделать тезис, так как большинство, на мой взгляд, восприняло, что речь идет о тестировании именно private-методов, хотя речь шла о приватной логике. В этой статье хочу проиллюстрировать практическим примером главный тезис. Под катом пример с небольшим анализом.
Перед вами перевод статьи Manjunath M, которая была опубликована на Bits and Pieces. Мы предлагаем прочитать ее тем, кто уже преодолел этап подготовки к миграции и приступает к следующему шагу.
Обычно компании рассматривают разные способы переноса приложений в облачное хранилище во время оценки и планирования портфеля — на второй стадии миграции. Задумываются также над тем, какие приложения будет легче перенести и что повлечет за собой их миграция. Именно на этом этапе разработчик понимает, насколько сложны и взаимозависимы компоненты его среды разработки. С его точки зрения, многое может пойти не так.
Представляем вашему вниманию перевод статьи Scott Domes, которая была опубликована на blog.bitsrc.io. Узнайте под катом, почему компоненты должны быть как можно меньше и как принцип единственной ответственности влияет на качество приложений.
Представляем вам перевод статьи Sukhjinder Arora, опубликованной на ресурсе Bits and Pieces. Узнайте под катом о функциях высшего порядка в JavaScript и о некоторых других функциях, встроенных в этот язык.
В статье описывается вариант обеспечения доступности развернутого в облаке веб-сервиса при возникновении сбоев в работе дата-центра. Предлагаемое решение основано на компромиссе, состоящем в частичном дублировании: в другом дата-центре разворачивается резервная система, которая может работать в режиме ограниченной функциональности при недоступности основного ЦОДа. Данная схема в первую очередь нацелена на применение при кратковременных сбоях, но также предусматривает возможность быстрого превращения дублирующей системы в основную в случае масштабных проблем.
Вот решил поделиться статьей, оригинал которой я опубликовал у себя на блоге вот здесь…
— Для начала, обычное предупреждение: я не претендую на истину в последней инстанции и то, что я рассказываю, основано лишь на моем персональном опыте. Наверняка в России и СНГ есть фирмы, которые набирают других людей и работают совсем иначе чем те, с которыми мне довелось столкнуться. Чтобы далеко не ходить, приведу в пример фирму, возглавляемую моим научным руководителем в университете профессором Андреем Николаевичем Тереховым. Сейчас он возглавляет вполне успешную фирму, специализирующуюся на выполнении софтверных проектов под заказ, включая и изрядную долю оффшорных проектов от западных заказчиков. Так вот, я уверен, что у него-то как раз все точно поставлено как надо и ребята правильные и все хорошо. К сожалению, с его фирмой мне работать не довелось, а с теми, с которыми мне довелось работать, работали так…
Кросс-пост с персонального (http://www.eldar.com/node/200) как обычно…
Да-да, знаю… Очень необычно ругаться на code reviews (ревизии кода), особенно в мире где они воспринимаются чуть ли не как одиннадцатая заповедь, за неуважение к которой легко угодить на костер… Так что, потерпите немного ереси, я все обьясню!
Итак… Я не говорю, что ревизия кода – это плохо. Просто все в нашем грешном мире имеет свои преимущества и недостатки. Или как говорили утомленные мудростью греков римляне – cons et pros. Так вот, я хотел бы обратить ваше внимание на некоторую con ревизии кода, которая обычно не упоминается вслух...
Исключая тех, кому повезло быть богатыми, большинство людей занимают деньги, когда начинают свой первый бизнес. И они надеются, что эти инвестиции себя оправдают. Это пример того, как долг может быть хорошей штукой.
