Рубрика «проектирование»

Отечественная САПР-платформа nanoCAD Plus 10: универсальный комплекс для тех, кто проектирует - 1


Весной 2018 года наша компания («Нанософт») выпустила в свет nanoCAD Plus 10 – новую версию российской САПР-платформы, приуроченную к 10-летию компании. Подумать только – 10 лет мы создаем nanoCAD на благо наших пользователей! Что нового появилось в продукте? Несколько месяцев назад я отвечал на этот вопрос в рамках YouTube-трансляции, которую посетили 600 человек. Сам по себе такой формат презентации был для нас нов, технически сложен, но, по-моему, получилось здорово – сама презентация заняла один час, а потом я еще 50 минут отвечал на вопросы слушателей. И в результате мы получили уникальную видеопрезентацию, в которой подробно и наглядно рассказываем о новшествах продукта. На сегодняшний день запись трансляции посмотрели более четырех с половиной тысяч человек, которые в основном ставят лайки. Если вы пропустили трансляцию, смотрите запись – рекомендую.

Но в процессе подготовки презентации я не раз ловил себя на мысли, что, рассказывая о новшествах продукта, упускаю нечто большее – концентрируясь только на новшествах, отсекаю общее позиционирование продукта. Во что превратился nanoCAD за 10 лет разработки? Чем он удобен и почему должен быть полезен нашим пользователям? Какие у него ключевые преимущества? Вообще, в целом, что такое платформа nanoCAD? Поэтому я решил написать статью-обзор нашего программного комплекса для тех, кто не готов собирать новинки, разбросанные по разным версиям, а хочет в рамках одной статьи получить полное представление о nanoCAD. Фактически это будет обзор современного российского САПР-решения и потенциальных направлений развития САПР, а также ответ на вопрос, куда движется nanoCAD как продукт.

Итак, российская платформа nanoCAD Plus глазами разработчика: что это и для чего?Читать полностью »

Здравствуйте все.

В последнее время у нас получалось публиковать в блоге преимущественно узкоспециальные материалы, сильно связанные с исследованием рынка и формированием издательской политики. Полагаем, что в обозримом будущем пятничные публикации такими и останутся — нам очень интересны ваши комментарии, голосование и замечания по поводу рассматриваемых нами книг и авторов. Но теперь появятся еще и понедельничные публикации, которые гораздо более опосредованно связаны с нашими стратегическими поисками, а (на первом этапе) будут представлять наш «editor's pick» с сайта Medium.

Первая такая статья принадлежит перу Дерека Мея и переведена сегодня
Читать полностью »

image

Привет, %username%!

Ты наверняка знаешь, что такое API интерфейсы и то, как много от них зависит в твоем проекте. Более того, я так же полагаю, что ты уже знаком с тем, что такое API first подход и знаешь, что Swagger и его Open API являются одними из самых популярных инструментов, помогающих ему следовать.

Но в этой статье я хочу рассказать про подход к реализации API first, концептуально отличающийся от того, что предлагает Swagger и Apiary. Во главе идеи стоит понятие Single contract и возможность его реализации на базе RAML 1.0.

Под катом:

  • Краткое описание принципов API first;
  • Single contract – ввод понятия, предпосылки к появлению, рассмотрение возможности его реализации на базе OAS (Swagger);
  • RAML + annotations + overlays как база для Single contract, примеры;
  • Проблемы RAML, концептуальные разногласия разработчиков;
  • Идея SaaS сервиса на базе вышеизложенной идеи (картинка прототипа сверху).

Читать полностью »

Как Unsplash масштабируется силами небольшой команды - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Читать полностью »

Масштабирование Unsplash маленькой командой: 8 человек и 10 миллионов запросов в сутки - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Читать полностью »

Как восемь человек масштабируют highload-проект. Опыт Unsplash - 1

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Читать полностью »

Почему именно больница?

А почему бы и нет? Это хороший пример. Проект везде проект: плюс-минус те же стадии, та же схема управления, документооборот, работа с рисками, контроль качества и так далее. Везде есть требования и к оборудованию, и к помещениям, и к ПО. Вы спросите, какие могут быть требования к помещениям в Информационной Системе? Очень просто: расположение рабочих мест операторов, сервера — и тем и другим потребуется кондиционер. Вот уже и требования к помещениям. И вряд ли нынче кто-то сомневается, нужно ли больнице ПО. Если вы хотите идти в ногу со временем, перед вами встанет задача создать автоматизированное лечебное учреждение с электронными медицинскими картами, где врачи делают осмотр с планшетами, а, например, санитарки отмечают вымытый туалет не на листике, а в телефоне. Требований к ПО в данном случае будет предостаточно. А как только потребуется ПО, появится необходимость установить сервера, куда-то посадить админа и операторов. Все взаимосвязано.

Мы выбрали строительный проект, потому что на нем проще всего продемонстрировать, как спроектировать ИС. Информационная система скрыта где-то внутри, мы ее не видим, а стены — вот они перед нами: кривые и косые, с тупиковыми коридорами, потому что проект был сделан на коленке, да еще и заказчик свои требования менял сто раз по ходу пьесы.

Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы - 1

Программный код внутри (но этого никто не видит)

При чем тут больница, если мы разрабатываем ПО?

А вот и нет, дорогие разработчики, руководители, аналитики, тестировщики.

Не программное обеспечение вы разрабатываете… Возьмем Android, — это ПО. А если, например, перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.
Читать полностью »

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

Как мы писали сетевой код мобильного PvP шутера: синхронизация игрока на клиенте - 1
Читать полностью »

25 ошибок начинающего программиста - 1

Научитесь выявлять их. Выработайте привычки избегать их.

Цель этой статьи не загнобить новичков за типичные ошибки, а научить выявлять их и избегать. Порядок перечисления – случайный.

От переводчика

Иногда бывает трудно объяснить простыми словами казалось бы банальные вещи: зачем использовать гит, в чем фишка инкапсуляции, зачем писать тесты, как планировать свой код, рефакторить чужой и т.д. Мне показалось, что в этой статье компактно собраны важные «гуманитарные» аспекты программирования. Что-то вроде морального кодекса, ориентира и мотиватора в принятии решений, связанных с написанием кода.

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

В прошлой статье я описал технологии и подходы, которые мы используем при разработке нового мобильного fast paced шутера. Т.к. это была обзорная и даже поверхностная статья — сегодня я копну глубже и подробно расскажу, почему мы решили написать собственный ECS-фреймворк и не стали использовать существующие. Будут примеры кода и небольшой бонус в конце.
Как и почему мы написали свой ECS - 1
Читать полностью »