Рубрика «разработка по»

Доцент Лаборатории разработки промышленного ПО Университета Иннополис Джу Йонг Ли предложил лучшее исследование в области скоростной автоматизации устранения багов и вошёл в десятку победителей The Facebook Testing and Verification Research Awards. Всего на грант прислали заявки 145 исследователей со всего мира. Учёный рассказал нам о работе над своим исследованием.

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

Как работает SystemUI в Android - 1

В этой статье я разберу архитектуру и принцип работы основного приложения Android — SystemUI. Меня заинтересовала эта тема, потому что мне интересно, как устроена система, которой пользуется такое огромное количество пользователей и для которой ежедневно выкатываются тысячи приложений в Google Play или просто на просторы интернета. Помимо этого меня интересует вопрос информационной безопасности Android и создаваемых под него приложений.

В системе Android, SystemUI — это приложение, путь к исходному коду которого находится в platform_frameworks_base/packages/SystemUI/, на девайсе оно находится в system/priv-app/-SystemUI.

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

Разработка… она как наркотик — систему пишут, пишут, ведь «прет» же. А потом, вдруг оказывается — «алименты» нужно платить. А любое изменение системы влечет гору ошибок. А ведь еще в начале прошлого века великий Курт Гёдель предвидел это и строго доказал, что даже в арифметике у нас не хватает ума, чтобы выразить все ее законы без противоречий. А в программировании и подавно — мы начнем наступать себе на ноги и запутываться. Что, в общем-то, и происходит: то ноутбук ночью включается и перезагружается, то мобильные приложения сыпят ошибками так, что они из кармана начинают выпадать и разбегаться, бранясь и попискивая, по полу.

А как вам модные нынче бета-версии всего и вся? Cкоро самолеты начнут выходить в альфа-бета версиях, похоже.

Но ведь можно же программировать без ошибок, чтобы душа радовалась и пиво попить с клиентом было не только приятно, но и безопасно!

Сбор требований к программному проекту — без купюр - 1

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

Всем привет.
Написал библиотеку для обучения нейронной сети. Кому интересно, прошу.
Читать полностью »

1. Введение

В наше время для разработки программного обеспечения приходиться приложить не мало усилий. Слишком много времени тратится на то что логично было бы возложить на компьютеры выбор методологи, проектирование, написание технического задания, тестирование все это делает человек и делает очень медленно. Но возможно ли это в принципе? Доктор технических наук Максим Щербаков в своей лекции «Нейронные сети: maths & magic» ответил: «Да, это возможно». Хорошо иметь автоматизированного помощника, который решит задачу просто имея некие критерии и шаблоны при этом платить ему не надо и сделает он это в кратчайшее время, но какие конкретно задачи могут решать нейронные сети в наше время? Развитие машинного обучения в наши дни идет семимильными шагами не сегодня так завтра машины смогут заменить человека в рутинных задачах. Составление технического задания не самое приятное занятие особенно из-за необходимости расписать все крайне подробно и по форме (подробнее в 4 пункте). Каждая компания выбирает определенную методологию разработки программного обеспечения и меняет её крайне редко. Как же быть если для проекта другая методология подходит лучше прежней или нынешняя не подходит вовсе? Логично было бы заменить, но какую выбрать (подробнее в 5 пункте)? Правильное тестирование должно занимать приличное количество времени и людей. Довольно затратно и долго (подробнее в 6 пункте). Нейронная сеть удешевит и ускорит все эти этапы.
Читать полностью »

Как правильно чистить лук, или Почему разработка ПО выходит из-под контроля - 1

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

Складывается ощущение, что проект зажил собственной жизнью и пытается сожрать вас.

Как правильно чистить лук, или Почему разработка ПО выходит из-под контроля - 2

Как так случилось? Может, наняли плохого разработчика? Кто-то ошибся в планировании проекта? А вдруг сама идея проекта была ужасной?

Возможно. Но часто проект бывает с самого начала обречен на провал из-за недопонимания одного важного момента.

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

Это предположение — неверно.

Проект — это не лист бумаги, не двумерный объект — у него есть глубина.

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

Переведено в AlconostЧитать полностью »

Разработка через тестирование (TDD) – отличный способ повысить качество и надежность кода. Этот же подход может быть распространен и на разработку требований. Он называется "Разработка через приемочные тесты" – acceptance test driven development (ATDD). Сначала я присматривался к этому подходу, потом пробовал применить, потом долго тюнинговал, чтобы приспособить его под мои нужды, и теперь хочу поделиться мыслями. И для себя еще раз разложить все по полочкам.

В этой статье я расскажу небольшое введение в тему. Пример будет совсем простой и скорее для иллюстрации. А в следующей статье постараюсь поделиться историей, как я применял ATDD на практике при разработке настоящей фичи в реальном продукте.

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

История фреймворка React: как Фейсбук приобрел Инстаграм и почему это привело к открытию исходного кода React.js

Как Фейсбук приобрел Инстаграм и почему это привело к открытию исходного кода React.js - 1

Сегодня React — одна из самых популярных в мире библиотек JavaScript для пользовательского интерфейса: более 70 тыс. «звезд» на Гитхабе, не менее 1100 авторов и миллионы скачиваний каждый месяц — кроме того, этот фреймворк используется более чем в 4 тыс. компаний. Но когда Фейсбук впервые показал React миру, это мало кого обрадовало.

Мы решили погрузиться в историю рождения одной из самых популярных технологий в мире разработки ПО — React, и пригласили Пита Ханта (Pete Hunt), стоявшего у истоков этой библиотеки (сейчас он генеральный директор компании Smyte), чтобы он наконец-то рассказал о том, для чего создавали React, почему эта технология стала популярной в Фейсбуке после приобретения Инстаграма, и как она в итоге вышла в люди.

Основные моменты

От приложения Facebook Camera к приобретению Инстаграма


Марк (Цукерберг) собрал всех и говорит: «Мобильные устройства «выстрелят», поэтому срочно бросаем всё и переводим ресурсы на мобильные разработки». Мне казалось, это какая-то сумасшедшая идея: мы не могли поддерживать работу самого большого фотосайта в сети, имея горстку людей в команде. Совершенно бессмысленно переводить людей на разработку приложений для iOS и Android, которые составляют совсем небольшую долю нашего трафика. Но оказалось, что Марк был на 100% прав — поэтому я и не генеральный директор Фейсбука…

Мы разработали приложение Facebook Camera, и даже гордились тем, что получилось… Но пришел Инстаграм — и наш проект канул в Лету…

Ребятам из Инстаграма дали гараж на территории Фейсбука, где можно было сидеть и спокойно пилить свою идею. Они пользовались надежными системами безопасности Фейсбука, но кроме того продолжали использовать AWS, а еще — разрабатывали собственную стратегию продукта, насколько я могу судить… И я был первым сотрудником из Фейсбука, которого перевели в Инстаграм…

Переведено в AlconostЧитать полностью »

Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО

Не путайте разработку ПО и программирование - 1
Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.

Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!

Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.

Чтобы стать разработчиком, уметь программировать недостаточно.

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

Мне нравится такая аналогия: каждый может ради собственного развлечения петь в ду́ше, но вы же не ставите треки с записями этого пения на вечеринке — вы обращаетесь к произведениям профессиональных музыкантов.

Хотите еще аналогий? Пожалуйста:

  • В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.
  • Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
  • Никто не зовет соседа — мастера на все руки построить дом с нуля.

Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО.

Переведено в AlconostЧитать полностью »

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »