Риски при разработке программного обеспечения: как с ними справляться?
Любой проект по разработке мобильных приложений связан с определенными рисками той или иной степени. Риски могут различаться в зависимости от характера проекта, но в целом их можно разделить на 5 категорий:
Читать полностью »
Я разработчик программы для мониторинга сети Network MACMonitor.
В процессе развития программы возникла задача: определить за какими компьютерами работают пользователи и связать эту информацию с портами сетевых устройств. В этой статье хочу написать, как мне удалось это сделать.
В наше время для разработки программного обеспечения приходиться приложить не мало усилий. Слишком много времени тратится на то что логично было бы возложить на компьютеры выбор методологи, проектирование, написание технического задания, тестирование все это делает человек и делает очень медленно. Но возможно ли это в принципе? Доктор технических наук Максим Щербаков в своей лекции «Нейронные сети: maths & magic» ответил: «Да, это возможно». Хорошо иметь автоматизированного помощника, который решит задачу просто имея некие критерии и шаблоны при этом платить ему не надо и сделает он это в кратчайшее время, но какие конкретно задачи могут решать нейронные сети в наше время? Развитие машинного обучения в наши дни идет семимильными шагами не сегодня так завтра машины смогут заменить человека в рутинных задачах. Составление технического задания не самое приятное занятие особенно из-за необходимости расписать все крайне подробно и по форме (подробнее в 4 пункте). Каждая компания выбирает определенную методологию разработки программного обеспечения и меняет её крайне редко. Как же быть если для проекта другая методология подходит лучше прежней или нынешняя не подходит вовсе? Логично было бы заменить, но какую выбрать (подробнее в 5 пункте)? Правильное тестирование должно занимать приличное количество времени и людей. Довольно затратно и долго (подробнее в 6 пункте). Нейронная сеть удешевит и ускорит все эти этапы.
Читать полностью »
Я профессионально работаю с Unreal Engine уже более 9 лет. За это время я освоил множество специальностей и занимал разные должности в разработке игр: от разработчика-«пехотинца» до менеджера больших команд разработчиков игр и даже консультировал инвесторов игровых компаний.
В последнее время я работаю на себя, но время от времени предлагаю экстренные услуги «тушения пожаров» своим клиентам, которые находили меня по сарафанному радио. Сложно объяснить, в чём конкретно заключаются эти услуги, но больше всего они похожи на работу аварийного сантехника. Вы точно не захотите оказаться в такой ситуации, когда приходится его вызывать.
Если у игровой компании в Лос-Анджелесе появляется проблема с Unreal Engine 4, которую никто не может решить, в конце концов звонят мне. Я пишу эту статью, чтобы объяснить, почему мне звонят, как избежать необходимости таких звонков, и что я обычно делаю, получив такой звонок.
Большинство проблем разработки игр хорошо понятно тем, кто находится «в траншеях», но эти проблемы пролетают над головами менеджеров и руководства. Кроме того, похоже, подобные статьи читают только люди из траншей на передовой, а не те, кому они действительно необходимы.
Читать полностью »
Это продолжение статьи: Что делать, если нужно создать инновационный продукт в традиционной компании?
Сегодня я расскажу вам три альтернативных модели поведения предпринимателя, которые чаще всего вижу.
Фермер из Айовы Рей Кинселла в недоумении, так начинается фильм «Поле чудес». Последнее время он постоянно слышит голос, который советует ему построить бейсбольное поле на месте его кукурузных угодий. Кому-то, возможно, такое предложение и показалось бы начисто лишенным смысла. Но не Рею. Ведь его покойный отец когда-то был просто помешан на этой игре. Любящий сын решает последовать совету. И вот поле построено, и на нем появляется призрачная команда легендарных игроков. Рей не столько напуган, сколько озадачен. Чтобы понять смысл удивительных событий, он начинает собственное расследование…То, что слышит герой, это фраза «Built it and they will come».
Читать полностью »
Сегодня React — одна из самых популярных в мире библиотек JavaScript для пользовательского интерфейса: более 70 тыс. «звезд» на Гитхабе, не менее 1100 авторов и миллионы скачиваний каждый месяц — кроме того, этот фреймворк используется более чем в 4 тыс. компаний. Но когда Фейсбук впервые показал React миру, это мало кого обрадовало.
Мы решили погрузиться в историю рождения одной из самых популярных технологий в мире разработки ПО — React, и пригласили Пита Ханта (Pete Hunt), стоявшего у истоков этой библиотеки (сейчас он генеральный директор компании Smyte), чтобы он наконец-то рассказал о том, для чего создавали React, почему эта технология стала популярной в Фейсбуке после приобретения Инстаграма, и как она в итоге вышла в люди.
Марк (Цукерберг) собрал всех и говорит: «Мобильные устройства «выстрелят», поэтому срочно бросаем всё и переводим ресурсы на мобильные разработки». Мне казалось, это какая-то сумасшедшая идея: мы не могли поддерживать работу самого большого фотосайта в сети, имея горстку людей в команде. Совершенно бессмысленно переводить людей на разработку приложений для iOS и Android, которые составляют совсем небольшую долю нашего трафика. Но оказалось, что Марк был на 100% прав — поэтому я и не генеральный директор Фейсбука…
Мы разработали приложение Facebook Camera, и даже гордились тем, что получилось… Но пришел Инстаграм — и наш проект канул в Лету…
Ребятам из Инстаграма дали гараж на территории Фейсбука, где можно было сидеть и спокойно пилить свою идею. Они пользовались надежными системами безопасности Фейсбука, но кроме того продолжали использовать AWS, а еще — разрабатывали собственную стратегию продукта, насколько я могу судить… И я был первым сотрудником из Фейсбука, которого перевели в Инстаграм…
Переведено в AlconostЧитать полностью »
Мы делаем ПО для систем видеонаблюдения с функциями видеоанализа, и это — коробочный продукт. А коробочный продукт в одинаковом виде предоставляется сразу многим пользователям и используется всеми ими таким, какой он есть.
Имеет ли значение, делаем мы универсальный продукт для многих или разрабатываем индивидуально для конкретного пользователя? Когда речь идет о видеоанализе, это имеет просто принципиальное значение. Читать полностью »
Наша команда занимается разработкой интеллектуального ПО для систем IP-видеонаблюдения. За 9 лет существования мы создали десятки функций и модулей видеоанализа, столкнулись с сотней проблем и одержали неменьше побед. В своем блоге Macroscop мы расскажем о части из них, поделимся своим видением процесса разработки и раскроем некоторые свои технологии.
Несколько лет назад мы определили низкую популярность одной из наших функций — функции интерактивного поиска,- по тому, что пользователи не обращались в компанию с вопросами или проблема в работе с ней. Когда телефон техподдержки молчит – это дурной знак для разработчиков.
C модулем подсчета посетителей было все наоборот. Пользователи не просто покупали и устанавливали его, они им реально пользовались! И поэтому регулярно звонили с вопросами в техподдержку, писали свои пожелания, рассказывали о нестандартных способах использования и, конечно, делились сложностями в работе. Читать полностью »
Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!
Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.
Чтобы стать разработчиком, уметь программировать недостаточно.
Научить программировать можно любого — это легко. Писать простые программы, которые работают у конкретных людей на конкретных машинах, может почти кто угодно, но никто не гарантирует, что те же программы будут работать в других условиях.
Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду́ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.
Хотите еще аналогий? Пожалуйста:
Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО.
Переведено в AlconostЧитать полностью »
Не секрет, что правильно выстроенные бизнес-процессы нужны всем.
Отдельные граждане, отделы и целые компании с холдингами бегают кругами и воют о необходимости правильного обустройства всех и всяческих процессов. Всё должно быть посчитано, измерено, запланировано и выполнено в срок, в строгих рамках бюджета. Метрики и KPI, предсказуемость и прозрачность.
Везде должен быть “внедрён” Agile. Все должны мыслить категориями Lean. Все должны думать о Business Value.
И, будучи разбуженными ночью, — мгновенно ответить на вопрос: “каков LTV нашего пользователя?”
Отличный, рациональный подход.
В разработке программного обеспечения давно и прочно обосновался тренд “не изобретай велосипеда”.
Нужно разработать инсталлятор для нашего мега-продукта? Интегрироваться с внешней системой? Разработать кучу отчётов?
Не умничай, бери коробочное решение. Сэкономишь кучу времени, нервов, и, как результат, — денег компании.
А если помножить это на тенденцию снижения среднего уровня технической квалификации инженерных кадров, — это отдельная тема, завязанная на многолетнее превышения спроса над предложением, — то вообще получается отлично. Поминутно вейпая и попивая смузи, можно строить целые системы, просто интегрируя готовые блоки при помощи быдлокода и такой-то матери быстрого прототипирования.
Поэтому — не изобретай велосипеда и не умничай. Используй готовое, а кривые руки умную голову прикладывай там, где интеграция по какой-то причине вдруг не работает.
Отличный, рациональный подход.
Но самое забавное, как всегда, — то, что может случиться на стыке двух отличных, рациональных принципов. Давайте попробуем рассмотреть абстрактный пример, выгодно оттеняющий всю глубину этой проблемы.
