Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

INTRO

Добрый день, уважаемое сообщество.
Позвольте представиться. Я бизнес-аналитик, уже десять лет работаю в области разработки заказного программного обеспечения, в последнее время совмещаю роли аналитика и руководителя проектов.

Одним из болезненных вопросов в разработке ПО всегда был и остаётся процесс документирования этой самой разработки. Вам доводилось приходить на проект, который делают уже пару лет, но, при этом, вы никак не можете с ним разобраться, потому что из документов есть одно техническое задание, да и то написано в самом начале и не отражает и половины функционала системы? Мне доводилось. И это, честно говоря, очень печальное и байтораздирающее зрелище.
Поэтому на всех своих проектах я стараюсь изначально построить процесс так, чтобы неопознанного и неописанного функционала не было, все члены команды вовремя получали актуальную информацию и вообще был мир во всём

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.

Одной из приятных особенностей технологии 1С:Предприятие является то, что прикладное решение, разработанное по технологии управляемых форм, может запускаться как в тонком (исполняемом) клиенте под Windows, Linux, MacOS X, так и как веб-клиент под 5 браузеров – Chrome, Internet Explorer, Firefox, Safari, Edge, и все это – без изменения исходного кода приложения. Более того – внешне приложение в тонком клиенте и в браузере функционирует и выглядит практически идентично.
Найдите 10 отличий (под катом 2 картинки):

Всем привет, меня зовут Александр Соколов, и я хочу рассказать, как сделал дома секвенатор – прибор для расшифровки ДНК. Рыночная цена такого прибора составляет около 10 миллионов рублей.

Эта статья является руководством по настройке сборки C++ проектов Visual Studio. Частично она сводилась из материалов разрозненных статей на эту тему, частично является результатом реверс-инжениринга стандартных конфигурационных файлов Студии. Я написал ее в основном потому что полезность документации от самой Microsoft на эту тему стремится к нулю и мне хотелось иметь под рукой удобный референс к которому в дальнейшем можно будет обращаться и отсылать других разработчиков. Visual Studio имеет удобные и широкие возможности для настройки по-настоящему удобной работы со сложными проектами и мне досадно видеть что из-за отвратительной документации эти возможности очень редко сейчас используются.

В качестве примера попробуем сделать так чтобы в Студию можно было добавлять flatbuffer schema, а Студия автоматически вызывала flatc в тех случаях когда это нужно (и не вызывала — когда изменений не было) и позволяла задавать настройки напрямую через File Properties

Наша команда занимается разработкой интерфейсов для четырех крупных проектов: Яндекс.Картинки, Яндекс.Видео и их версий для смартфонов. Разработка верстки поисковых сервисов в Яндексе обладает своей спецификой. Задачи стекаются с разных сторон: от менеджеров, разработчиков бэкэнда, поиска, проявляются баги и т.д. Внедряются новые фичи, требующие отображения в верстке. Все это стекается в наш таск-трекер (JIRA).

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



В конечном итоге большинство наших проблем удалось решить при помощи Agile Board и Scrum, но пришли мы к этому далеко не сразу, а поэтапно.

В процессе разработки игры в текстовом режиме, мне пришлось нарисовать больше сотни анимационных ASCII спрайтов. После релиза игра получила неожиданно хорошие отзывы и было принято решение делать продолжение. Рисуя спрайты для первой части и перепробовав с десяток вариантов выбора цвета и несколько десятков различных палитр, я понял, что нужен свой, «идеальный» набор цветов на все времена. За сотни и сотни часов рисования, сложились следующие критерии идеальности палитры:

• Краткость: небольшое количество цветов в палитре. Весь набор цветов можно охватить одним взглядом.
• Полнота: цвета палитры должны равномерно и достаточно плотно заполнять цветовое пространство.
• Дискретность: цвета палитры должны отличаться друг от друга на глаз.
• Группировка: цвета должны быть удобно сгруппированы для быстрого нахождения нужного.

Оказалось, что можно подобрать набор из ровно 233 цветов, который удовлетворит всем этим критериям.

Дано: собственные и аутсорс-проекты, некоторые участники работают удаленно.

Требуется: необходимо быстро назначать задачи исполнителям, планировать спринты, трекать выполнение и статусы, визуализировать процессы и делиться результатами с заказчиками.

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

Изначально сервисов было более 100, но постепенно список сокращался, и мы остановили наш выбор на трех, удовлетворяющих вместе наши нужды лучше всего: Jira, Slack и GanttPro. Но, если вдруг эти сервисы не помогут вам в планировании задач и работы с командой, делюсь с вами полным списком:

Процесс поиска очень часто усложняется тем, что все сервисы, как один, пишут «Лучший сервис, помогающий превратить ваши идеи в реальность и реализовать ваши проекты. Сегодня.». Так, а что вы делаете-то? Поэтому в этом списке без лишних эпитетов, только что какой сервис умеет. :)

Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.



Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.

Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):

pg_dump: Oumping the contents of table “ws_log_smevlog” failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid page in block 4123007 of relatton base/16490/21396989
pg_dump: The command was: COPY public.ws_log_smevlog [...]
pg_dunp: [parallel archtver] a worker process dled unexpectedly

Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…

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

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

Достаточно давно хотел освоить сабж, но всё были другие более приоритетные дела. И вот настала очередь кросскомпиляции.

В данном посте будут описаны:

1. Инструменты
2. Элементарная технология кросскомпиляции
3. И, собственно, HOW2

Кому это интересно, прошу под кат.

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


Это КДПВ блок рекуперации/регенерации. Надеюсь, ни у кого нет трипофобии?

Итак, всё началось с духоты. Точнее, с утепления квартиры слоем экструзионного пенополистирола по всему периметру (панельная 9-этажка родом из 80-х, с кучей сквозящих углов). В результате чего, квартира стала условно герметичной и вопрос свежего воздуха встал в полный рост.

3D принтер Anet A8 — один из самых дешевых моделей принтеров из Китая. Построен он на базе известной модели Prusa i3. За ту цену, за которую предлагают его производители, Вы вряд ли купите принтер в России. Из преимуществ можно отметить небольшую стоимость, достаточно большой максимальный размер модели и, самое главное, подогреваемый стол. Обзоров по этому принтеру уже немало, поэтому я напишу небольшой список доработок, благодаря которым Ваш принтер станет печатать лучше или улучшится его косметический вид.

Банан велик, а кожура еще больше…
(журнал «Техника — молодежи» №8 за 1986 год)

Кожуре банана досталась незавидная участь. Если кожицу яблок используют хотя бы для получения яблочного пектина, то в случае банановой кожуры путь один — в мусорный контейнер… А ведь вещь непростая, она и поскользнуться поможет, и этилен для созревания выделит. И кроме того, с такой простой и незамысловатой штукой как кожура связаны такие глобальные вещи, как АНТИпитательные вещества, нелетальный наркотик бананадин и почернение кожи от загара. В общем, предлагаю разобраться и восстановить фитосправедливость.
За подробностями — под кат.

Не очень строгий перевод материала mrbook.org/tutorials/make Мне в свое время очень не хватило подобной методички для понимания базовых вещей о make. Думаю, будет хоть кому-нибудь интересно. Хотя эта технология и отмирает, но все равно используется в очень многих проектах. Кармы на хаб «Переводы» не хватило, как только появится возможность — добавлю и туда. Добавил в Переводы. Если есть ошибки в оформлении, то прошу указать на них. Буду исправлять.

Статья будет интересная прежде всего изучающим программирование на C/C++ в UNIX-подобных системах от самых корней, без использования IDE.

Компилировать проект ручками — занятие весьма утомительное, особенно когда исходных файлов становится больше одного, и для каждого из них надо каждый раз набивать команды компиляции и линковки. Но не все так плохо. Сейчас мы будем учиться создавать и использовать Мейкфайлы. Makefile — это набор инструкций для программы make, которая помогает собирать программный проект буквально в одно касание.

Как вы думаете, сколько операций можно сделать на одном глазу? Клинический случай одного из моих пациентов подтверждает, что более 20 операций разного рода – не предел. Хотя, вне сомнения, этот случай – рекорд для России и мировой офтальмологии.

В 1978 году все было банально – был 18 летний мальчик (назовем его «А»), который хотел стать летчиком-испытателем как его отец. Этому мешала слабая близорукость правого глаза – всего минус 1, для жизни не мешала, но будущему пилоту нужно было хорошее зрение. Он решил подправить оптику одного глаза путем кератотомии – старого «ручного» метода коррекции в институте Фёдорова (конечно, по знакомству), но что-то пошло не так. Это была первая операция. Затем еще четыре в России, затем еще семь – в Швейцарии. Летчиком он не стал, зато стал олигархом, человеком, управляющим серьезными бизнес-проектами, но не управляющим ситуацией со своим зрением.

Ко мне «А» попал совершенно разочарованный в мировой офтальмологии, со зрением 10%, невозможностью коррекции стандартными способами и высоким внутриглазным давлением. И это был молодой 50-летний бизнесмен, по жизни — успешный (это важно – потому что дальше тоже не все пошло «так»). Так вот – следующие восемь операций – мои. И хотя мы рассчитывали, что одной-двух будет достаточно – пришлось пережить почти тотальную офтальмохирургию – все возможные виды операций.

Кстати, была бы вместо кератотомии коррекция СМАЙЛ (ReLEX SMILE) или, хотя бы, Femto-LASIK – не о чем бы было писать – ничего подобно при них невозможно!

Собственно, изучая данную тему, было перерыто много сайтов, но нигде толком ничего не объяснялось, либо информация была по устаревшим ныне протоколам. Это и послужило своеобразным пинком для создания этого HowTo. Это будет не детальный разбор всех возможных проблем, но немного теории и описание некоторых вещей которые для кого-то являются банальщиной, а у кого-то (вроде меня) вызвали трудности и потерю времени на поиск решения. Сразу предупрежу — здесь не рассматривается как поднять сокет-сервер на PHP, подобной информации в интернете навалом. Буду исходить из того, что сокет-сервер уже существует и надо лишь научить его общаться через вебсокеты.
Итак, хватит лирики, теперь к делу!

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

HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское приложение может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом.

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

Здравствуйте. Меня зовут Владимир и я хочу немного рассказать об автомобиле-роботе команды из Нижнего Новгорода НАМТ, победившей на 3-их Всероссийских соревнованиях автомобилей роботов РОБОКРОСС-2012, проходивших в городе Волоколамск. Здесь уже публиковался отчет команды из Саратова MobRob, теперь хочу рассказать о наших мытарствах.

О правилах

Соревнования заключались в следующем: необходимо было в автоматическом или телеуправляемом режиме проехать от точки старта по полю, попасть в ворота и передать оператору изображение трёх контрольных точек, а затем заехать в финишные ворота и там остановиться. GPS/ГЛОНАСС координаты ворот и контрольных точек были заранее известны командам. Очки начислялись за быстроту прохождения маршрута (но регламент соревнований запрещал скорость больше 10 км/ч) и переданные изображения контрольных точек.

День добрый!
Хочу опубликовать отчёт об автономном роботе команды НАМТ, участвовавшей в соревнованиях «Робокросс 2013» и европейском «Eurathlon 2013».
На этот раз роботизировался не автомобиль, а электрический квадроцикл, так как система делалась с прицелом на Eurathlon, путёвку на который обеспечило первое место на «Робокросс 2012». Газель на горных дорогах была бы слишком габаритным и трудноуправляемым объектом. Одна МКПП добавляет много трудностей.

Вкратце о соревнованиях

Довольно подробно задание «Робокросса» описано в статье команды «АВРОРА», заслуженно занявшей первое место в конкурсе «Мул».
На «Робокроссе» задание «Мул» было взято с прошлогоднего Eurathlon. Робот должен в автономном режиме следовать за какой-либо меткой (не радиомаяком), затем вернуться в точку старта, объезжая динамические и статические препятствия на трассе.
На Eurathlon было задание «Автономная навигация» — заранее неизвестная дорога в горном лесу, даны координаты нескольких ключевых точек, которые необходимо проехать. Склоны и овраги в комплекте.

Приношу извинения за размеры фотографий, с моим интернетом они полдня заливались, с постоянными обрывами. Снова этого не вынесу! Спасибо, экс-ёта.