Уметь программировать конечно неплохо и гейм-дизайнеру, и музыканту, и художнику — тут спору нет. Но все же каждый должен быть профессионалом в своей области. Если начать распыляться — перестанешь быть профессионалом в своей сфере. По-моему так.
Arduino IDE основан на IDE для Processing, о чем, кстати, четко сказано на сайте Arduino. Так что никакой загадки тут нет. :) Язык для Arduino Software, кстати, тоже во многом позаимствован у Processing. Конечно, больше железячной специфики, но основа — одна и та же.
Дело в том, что если сначала пишется API как получится, а потом пост-фактум под него пишется документация, то качество этого API будет стремиться к нулю или даже дальше в минус бесконечность.
Дальше не читал (с).
Как предполагается сразу написать сразу документацию, а потом под нее подгонять код? Нет, ну это понятно в случае с библиотеками, подключаемыми ресурсами. Но на живом проекте такое попросту нереально. Допустим даже, с использованием такого подхода сделали продукт. Состоялся релиз. Получили фидбек от пользователей. Посидели, поговорили, подумали что добавить, что убрать, что поменять. Окей, составили тех-спецификацию. Насколько Вы уверены в том, что она просто вот возьмет и идеально с учетом всех хотелок ляжет на архитектуру? Я обычно уверен процента на 2-3 и редко ошибаюсь. Как правило, это пустая трата времени, по крайней мере на больших продуктах. Мелочевка одноразовая — тут не вопрос. Но там как правило и документация не сильно нужна. А в серьезных проектах, которые из многих модулей состоят — вот так просто взять и составить документацию по всем API и тех. задание по ней — это анрил. Нужна еще целая куча согласований по ходу разработки. Кому-то нужны данные в таком виде, кому-то в таком. На берегу в больших проектах редко получается договориться.
Руками править отдельно написанную документацию — это просто бессмысленная трата времени. Открыл проект, подправил код. Лезть еще и документацию править? Не проще ли перейти на некое количество строк вверх, подправить doxygen/javadoc документацию и продолжить работать?
Ну это, по крайней мере, более предсказуемое поведение. Хотя, если знать как это работает в JS — все тоже предсказуемо. Но для начинающих разработчиков — это, конечно, мрачный мрак.
Так ведь Java. Чем плохо? Статическая типизация, сайты писать — запросто. Мейнстрим? Вот тут вопрос. Почему-то ее относят к «кровавому энтерпрайзу», вот даже автор этой статьи. Хотя абсолютно ничего «кровавого» я в Java не вижу. Не более и не менее, чем еще один язык программирования с широкими возможностями. Выучить ее в любом случае лишним не будет, так как возможности действительно очень широкие. Практически все, что может потребовать разработка — запросто. Веб — легко, десктоп — пожалуйста, мобилки — только Андроид, но все же (хотя тут не уверен, возможно есть и под другие платформы уже свои костыли, поправьте, если не прав).
Законом такое регулировать довольно наивно. Человек захотевший, как в комментарии выше, соорудить ботнет — уже пошел против закона. Еще одно нарушение, боюсь, что его вряд ли остановит.
А вот решить ту же проблему на уровне браузеров и стандартов — вполне. Чтобы при доступе к «железячным» API запрашивалось разрешение, как сейчас происходит при запросе к гео-апи и к апи уведомлений. По-моему, довольно логичное и здравое решение.
Возможно глупый вопрос, но все же — почему настолько важно производить ранжирование статей каждую минуту? Неужели от этого так сильно зависит объем читающей аудитории и статьи настолько быстро устаревают? Извиняюсь, если вопрос реально глупый, просто в СМИ не работал, поэтому не в теме.
Спасибо за замечание! Добавил в конце статьи. В принципе, приложение «одноразовое», о какой-то глобальной полезности речи идти не может. Но свою функцию выполнило на «отлично». Хотя есть в мыслях сделать на его основе «взрослое» приложение, с сервером, созданием своих опросов и так далее. Тогда и можно будет говорить о полезности. Но это, конечно, уже совсем другой уровень. Здесь была цель за пару вечеров сделать что-то, что можно минимально использовать, сплошной хардкод.
Лишь тем, что оно работает в офлайн-режиме на телефоне, на котором нет интернета, и его удобно запускать из основного меню телефона. А в остальном — да, это лишь HTML-страница с Javascript'ом, ничего более, как, впрочем, и большинство гибридных приложений.
Это, знаете, все же кому как. Мне, как, по большому счету, нативному разработчику под Android, было проще кинуть в активити WebView, чем тащить за собой такого монстра, как PhoneGap. Тем более, что для такого «серьезного» приложения, этого более чем достаточно. Цель приложения — запустить его один раз и забыть про него. Соответственно, никакой кроссплатформенности тут не нужно. А будет нужно — на iOS можно проделать ровно тоже самое. Как дела обстоят на других мобильных платформах, я не очень в курсе, если честно, но не думаю, что ситуация кардинально отличается. В случае появления необходимости в нативных API, всегда можно воспользоваться интерфейсами.
Это, конечно, написано. Но. Я сам вправе решать — хочу я лишиться гарантии или нет. Это мой выбор. Я же не требую замены принтера по гарантии. Давайте не будем подменять понятия.
А что гуглить то? Замене в маке подлежит почти все (кроме процессора, материнской платы и т. д.). Лишаешься гарантии? Да. А если она давно прошла? Тогда все ок.
Огромное спасибо!
Будем искать! (с)
А по поводу того, что оно из аппстора пропало — зная не понаслышке политику Эппл по отношению к разработчикам системных утилит, не удивлен… У них политика — мы лучше знаем как должна работать наша система. Точка. Жирная точка. Спорить и переубеждать бесполезно. К сожалению, и Гугл в своем плей-маркете в последнее время начинает идти в том же направлении…
Дальше не читал (с).
Как предполагается сразу написать сразу документацию, а потом под нее подгонять код? Нет, ну это понятно в случае с библиотеками, подключаемыми ресурсами. Но на живом проекте такое попросту нереально. Допустим даже, с использованием такого подхода сделали продукт. Состоялся релиз. Получили фидбек от пользователей. Посидели, поговорили, подумали что добавить, что убрать, что поменять. Окей, составили тех-спецификацию. Насколько Вы уверены в том, что она просто вот возьмет и идеально с учетом всех хотелок ляжет на архитектуру? Я обычно уверен процента на 2-3 и редко ошибаюсь. Как правило, это пустая трата времени, по крайней мере на больших продуктах. Мелочевка одноразовая — тут не вопрос. Но там как правило и документация не сильно нужна. А в серьезных проектах, которые из многих модулей состоят — вот так просто взять и составить документацию по всем API и тех. задание по ней — это анрил. Нужна еще целая куча согласований по ходу разработки. Кому-то нужны данные в таком виде, кому-то в таком. На берегу в больших проектах редко получается договориться.
А вот решить ту же проблему на уровне браузеров и стандартов — вполне. Чтобы при доступе к «железячным» API запрашивалось разрешение, как сейчас происходит при запросе к гео-апи и к апи уведомлений. По-моему, довольно логичное и здравое решение.
И вот опять GeekTimes в реестре… Поставил бы смайлик, но на деле то грустно…
Будем искать! (с)
А по поводу того, что оно из аппстора пропало — зная не понаслышке политику Эппл по отношению к разработчикам системных утилит, не удивлен… У них политика — мы лучше знаем как должна работать наша система. Точка. Жирная точка. Спорить и переубеждать бесполезно. К сожалению, и Гугл в своем плей-маркете в последнее время начинает идти в том же направлении…