Ваша программа делает процесс очень сложным, с бумажками проще и веселее. 99% функционала нужно убрать и сделать все как в бумажной версии… Паки слов должны быть уже готовы и разбиты на уровни. Про UI говорить не буду.
Ну это если рассматривать программу как продукт, для обучения программированию и just 4 fun то все отлично!
Использование таких хаков возможно только в глубоко неправильной архитектуре сервера, как минимум нужно закрывать такие вещи https.
А по факту ваша статья не относиться ни к GPS, ни к Node.js, к тематике хабра ее тоже притянуть весьма сложно, как воровать бенз, может лучше на форум водителей?
Довольно спорно утверждать что пылесос с мощностью 1300 Вт всасывает также как с мощностью 200 Вт. Просто понятие чистоты (и количество пыли) сильно изменились с тех давних пор.
Я бы сделал free to use версию, первый месяц бесплатно а потом часть кнопок лочится или нужно платить 0.99 в месяц. А за то что приглашаеш в апу друзей — каждый день подарок, новая кнопка.
Круто, в свое время было бы полезно иметь такой инструментарий (давно пересел за mac). Если оформить такое чудо как удобную gui тулзу можно даже деньги на наших программерских братьях рубить.
Для того что бы:
— Включать только когда темно, а не всегда
— Плавно включать и не тушить при повторном срабатывании
Хотя да конечно ардуину можно заменить чем то более простым, но зачем?
В заголовке не верное выражение. Весь смысл программистов — помочь пользоваться электроникой себе и другим. Не нужно всем их знать, у всех свои способности. Задача сделать так что бы пользоваться могли все.
Вам же не нужно знать как работает машина что бы на ней ездить (Ну если у вас нормальная машина конечно).
Я понимаю что это приложение лишь демонстрация и туториал.
Но даже на примере такого простого приложения видно что использование React не привело к особому ускорению или улучшению процесса разработки, нативный интерфейс был бы роднее, быстрее и более кастомизируем. Сделать такой просто интерфейс в XCode заняло бы минут 20-60 минут, но он бы имел ряд преимуществ. Но даже здесь видно что основной код все равно пришлось писать нативно или адаптировать другие модули.
Можно конечно сказать что кросс-интерфейс решения будут более эффективны на больших проектах, однако это не так, ибо с увеличением сложности возросло бы и количество хаков и тормозов, тем более на огромных проектах обычно хватает времени (денег) на нативную разработку.
Интересно услышать мнение сообщества для какой ниши применение таких инструментов оправдано (из моего опыта есть только миграция большого cordova проекта в нативный код, еще до конца первого цикла разрабоки по выше сказаным причинам).
1 Нативное приложение всегда лучше чем кроссплатформенное
2 Объяснять таким образом как указано выше можно только клиенту, специалист всегда знает в чем на самом деле разница и что указанные вами критерии к нативности отношения не имеют.
3 Любом более менее серьезное не нативное приложение при достижении возраста N будет переписано на нативный код под 1 платформу, лучше когда этот возраст 0.
Таким образом явно видно что выше указана просто очередная победа маркетологов над здравым смыслом.
Вот какие тезисы я вынес за время работы в этой сфере.
Все например, статья описывает то что известно и делается любым разработчиком с минимальным знаем основ http запросов. Ничего нового кроме того что Microsoft не позаботился о защите она не несет. Лучше бы вы написали статю как поднять тот же captionbot на своем сервере используя Сaffe, но это уже совсем другой уровень.
Ваш код будет непригоден к интернациональной поддержке, а значит не будет никому нужен (я говорю о серьезных потребностях) и будет выглядеть как херня. В продакшн это не нужно, разве что код более православный.
Все это напоминает мне наш с другом университетский проект по курсу трансляторов под названием «Сало» с синтаксисом на украинском языке, только этим мы занимались в рамках курсовой работы и были студентами. А не предлагали куда — либо внедрять.
Ну это если рассматривать программу как продукт, для обучения программированию и just 4 fun то все отлично!
А по факту ваша статья не относиться ни к GPS, ни к Node.js, к тематике хабра ее тоже притянуть весьма сложно, как воровать бенз, может лучше на форум водителей?
— Включать только когда темно, а не всегда
— Плавно включать и не тушить при повторном срабатывании
Хотя да конечно ардуину можно заменить чем то более простым, но зачем?
Вам же не нужно знать как работает машина что бы на ней ездить (Ну если у вас нормальная машина конечно).
Но даже на примере такого простого приложения видно что использование React не привело к особому ускорению или улучшению процесса разработки, нативный интерфейс был бы роднее, быстрее и более кастомизируем. Сделать такой просто интерфейс в XCode заняло бы минут 20-60 минут, но он бы имел ряд преимуществ. Но даже здесь видно что основной код все равно пришлось писать нативно или адаптировать другие модули.
Можно конечно сказать что кросс-интерфейс решения будут более эффективны на больших проектах, однако это не так, ибо с увеличением сложности возросло бы и количество хаков и тормозов, тем более на огромных проектах обычно хватает времени (денег) на нативную разработку.
Интересно услышать мнение сообщества для какой ниши применение таких инструментов оправдано (из моего опыта есть только миграция большого cordova проекта в нативный код, еще до конца первого цикла разрабоки по выше сказаным причинам).
2 Объяснять таким образом как указано выше можно только клиенту, специалист всегда знает в чем на самом деле разница и что указанные вами критерии к нативности отношения не имеют.
3 Любом более менее серьезное не нативное приложение при достижении возраста N будет переписано на нативный код под 1 платформу, лучше когда этот возраст 0.
Таким образом явно видно что выше указана просто очередная победа маркетологов над здравым смыслом.
Вот какие тезисы я вынес за время работы в этой сфере.
Все это напоминает мне наш с другом университетский проект по курсу трансляторов под названием «Сало» с синтаксисом на украинском языке, только этим мы занимались в рамках курсовой работы и были студентами. А не предлагали куда — либо внедрять.